Re: RE: Data Interoperability ... Why do some XML vocabularie
I strongly disagree with both the premise and all 3 conclusions > I have often heard it said, "To achieve data interoperability each application must interpret/understand the XML vocabulary in the same way." > > What better way to ensure the same interpretation/understanding than to use the same application! If everyone used the same application there would be no need for data interchangeability. "interchangeability" implies the possibility of > 1. If everyone uses the same app XML would be irrelevant. Thats not necessarily 'bad' but its not the best use case for XML. I disagree that there is always a "Prime App". There may be a "Prime Intended Purpose" or there may not be. App and purpose are not the same. The purpose may be concrete or abstract. Take for example a VCARD standard which essentially encodes a persons name,address and phone number. The "purpose" is to store and exchange this information with as *wide* a potential use ("App") as possible, not to restrict it. Imagine Printing cards, address books, email signatures, ... Better yet imagine you haven't yet imagined to what use it will be put. > I am led to these 3 conclusions: > > 1. When you create an XML vocabulary, specify the behavior of the XML vocabulary. Specify conformance requirements. Create a conforming Prime App. Create a test suite. Everyone use the Prime App. An XML vocabulary may not have an intended prime behaviour. see above > 2. Data interoperability is not achieved through shared understanding of the XML vocabulary. Data interoperability is achieved through shared usage of the Prime App. Data interchange is not achieved by shared use of a "Prime App" Data interchange is achieved by defining the common vocabulary so any app that wishes to use the information may. > 3. Creating an XML vocabulary without specifying its behavior is a bad idea. It is a recipe for delayed data interoperability at best, failed data interoperability at worst. For example, the XHTML vocabulary does not specify behavior. Each browser vendor had their own idea of the proper behavior of the XHTML vocabulary. The result was years of non-interoperability. It's taken over 10 years for the vendors to finally converge on a common browser behavior. Browsers could have had (theoretically) common behavior 10 years ago had the XHTML specification specified behavior of the Prime App (browser) along with conformance and test suites. Creating an XML vocabulary without behavior is a perfectly good thing to do. Specifying behavior is a orthogonal issue (or perhaps a subset depending on how you look at it). The browser (xhtml) issue is so complex that I would not take it as a good example for a solid basis on design principals. The problem there is that 'people' want different things from the same vocabulary, and not everyone can agree. But we are at a place in technology right now where were forced to somewhat agree based on the assumption there should be 'one standard' that covers everyone's desire. The result is somewhat of a mess right now. I wouldnt look at xhtml for an example of what XML is all about. -- David A. Lee firstname.lastname@example.org http://www.xmlsh.org
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format