OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] RE: Data Interoperability ... Why do some XML vocabulariesspecify meaning + behavior whereas others specify only meaning?

  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" 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 

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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS