daihozen

A few days ago, David Diamond posed a deceptively simple question on one of the LinkedIn Group sites (SOA SIG) - "Can Anyone Explain SOA In Simple Terms?" The barrage of widely varying responses that followed was, in a way, an eloquent answer to that question! I've had my own take on SOA for quite a while now, so this gave me the opportunity to validate my model against what other practitioners had to say. And I must say this: I'm more convinced than ever that the industry is horribly confused about SOA. There are those whose understanding of SOA is at a purely technology level (even some of those who profess to understand that SOA is not (just) about technology). And there are others who may understand SOA for all I know, but whose explanations tend to be couched in so much jargon that they're really hard to understand. In hindsight, David Diamond could not have asked a more insightful question. Well, this is my blog, so just as history is written by the victors,

I've long been a supporter of the JSON Schema initiative, and I was also happy to see developments like Orderly , which offered a simpler and less verbose format than JSON Schema. But Orderly introduces its own format, which necessitates conversion to JSON Schema before it can be used. Both approaches are unsatisfactory in their own way. One is too verbose and the other needs translation. All of this made me wonder if we aren't approaching the problem the wrong way. JSON Schema is a conscious effort to replicate in the JSON world the descriptive capability that XML Schema brings to XML. But is this the best way to go about it? I would like descriptive metadata about documents to be capable of being embedded inside the document itself, rather like annotations in Java programs. Indeed, this metadata should be capable of forming a "scaffold" around the data that then allows the data itself to be stripped out, leaving behind a template or schema for other data instances