All these Manichean (there is light and there is dark and you have to choose) approaches to data leave out that there are many hybrid approaches when they fit. For interactions between multiple partners or even versioning between different version of the same system, a canonical description of what information we are sharing and how to recognize what version is immensely useful. It is even better if that description can make itself available to tooling, to simplify programming and improve accuracy. People who dispute this should go all out and turn off all compiler bug checking as well – real programmers don’t need that…. The XSD is a fine tool for this, especially when supplemented by Schematron, CAM, or the like. It is an added advantage that the description itself can be transmitted and potentially understood by any client able to receive the data message. It is not uncommon for an information model described by XSD to be transmitted in JSON or in CSV, or in compressed XML, or in COAP. There are even standards committees working on standard JSON encodings for certain types of messages in the IETF, in OASIS, and in other places. The notion that JSON is distinguished from other formats because it never has process is a false one. Sometimes it does, sometimes it does not. Encoding is entirely separate from whether the information being encoded has been standardized or even documented. Interaction patterns can be document-exchange oriented (DAV, REST, much JSON) or message oriented (SOAP, COAP). The decision to use document-exchange or messaging patterns is often driven by matters such as security, composition, logging, or even pre-processing to improve core system scalability. Those issues are a long way from this argument. In not very complicated systems (or in control systems) the interaction pattern is very small and discrete, peeks and pokes at a distance. I have seen each of these remote peaks and pokes in XML, REST & SOAP, JSON, ASN, DNP, or any other messaging structure you care to name. XSD is not about committees, encodings, or interaction patterns. XSD is about documenting your work in a way which is machine readable. I have spent far too much of the least interesting hours of my career reverse engineering some gawdawful message that some not-as-clever-as-he thinks programmer, often long gone, has never bothered to document except by his buggy code. Committees are not immune to this. I have sat in a committee for months while someone tried to added their old 8-bit encoded error messages as top-level data type (see the 1 means the status is informational or error, and the 2 means internal or external, and the 4 and 8 is the 4 codes for the subsystems…, so it is logical to transmit the text “37” for advanced debugging…everyone will know what that means). I don’t care if your systems *ARE* only internal, and are designed only by yourself, and you write both sides of every message. Write down your decisions about messages. Develop your rules. Make them machine readable. If you do not, those who follow you in an incompetent organization will curse your name; in a competent organization, they will fire you—as they should. Life is too short to require that everyone who follows you do endless searches for the Mayan Codex to figure out your messages. Unless, of course, your code is all throw-away, Or perhaps if you are a hobbyist programming your aquarium bubbler. tc "If something is not worth doing, it`s not worth doing well " -- Peter Drucker
From: Uche Ogbuji [mailto:uche@ogbuji.net] |