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


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] Identifying Data for Interchange [was: XML Components]

[ Lists Home | Date Index | Thread Index ]

On Sat, 04 Jan 2003 12:03:50 -0500, Roger L. Costello <costello@mitre.org> 

> Instead, define precisely one, unambiguous "interchange standard".  This
> becomes the "lingua franca" interchange format.

Sigh.  The eternal optimism of nerds ;-)  that human factors can somehow be 
assumed away.   See http://www.sys-con.com/xml/articleprint.cfm?id=314 for 
Sean McGrath's take on this:

"My contention is that the failed industry-standard schema initiatives of 
the past did not fail for technical reasons; they failed for human reasons. 
There is a rich lore of experience here that the new wave of XML schema 
designers could do worse than mine for valuable insights. Those that don't 
learn from the mistakes of the past truly are doomed to repeat them. Apart 
from paying due regard to history, I think XML schema design needs to take 
a leaf out of the extreme programming book. Start with the customer (human) 
, do the smallest thing than can possibly work, and start using it. Never 
lose sight of the human creating the XML content or the human writing 
software to process the content."

> 1. You should never interchange data that may be calculated. Interchange 
> using the "fundamental data", from which calculations may be
> done.

Seems like a useful heuristic, but not a Thou Shalt Not ...  Ya gotta 
consider the processing capabilities of the devices producing and consuming 
the data, frequency with which data are interchanged, the bandwidth 
available ... I'm becoming a bit of  an Extreme Programming advocate in my 
dotage -- listen to what the customer wants and do the minimum that can 
achieve it before you worry too much about large scale abstractions and 
grand principles.

> 2. The more different ways data can be used, the higher the value of the
> data, the less application-specific it is, and the more suitable it is
> for data interchange.

Sure, but again see the XP people's rants on this subject: a lot more 
projects have failed because the developers put their effort into designing 
generalizeable, extensible abstractions up front than have failed because 
the code had to be refactored as requirements and technology changed.

> 3. Once you have identified good interchange data you then need to
> determine how to represent it.  There may be various ways to represent
> it.  However, you should pick precisely one, unambiguous representation
> for which there are algorithms to map to the other representations. This 
> becomes the "interchange standard".  Defining an interchange
> standard greatly reduces the complexity of all

Seems like a good principle, but also sounds like a political rathole 
because everyone wants the data to be in a form that they can easily 
produce or consume.  In a Technocracy where decisions are made on the basis 
of the Right Thing, this would be a very workable principle.  Someone tell 
me when they start to sell tickets on the starship heading for that planet 

> ...
> Okay.  That's a start.  I invite you to present your ideas on what
> characterizes good interchange data.  I invite your input on how to
> better express what I have presented above (e.g., do you agree with my
> term "high value data" to describe the data that suitable for being
> interchanged?  Can you think of a better/more accurate term?)

Sorry to be more than my usual cynical self.  I think you've got some good 
ideas here.  I'd be more interested in working backwards from success 
stories to see if these principles DO seem to have been exhibited than from 
adopting them as best practice guidelines in the absence of empirical 
evidence. Still, I agree with the general principle that the only standard 
schemas we're likely to encounter anytime soon will be EXCHANGE formats, 
and anything that can be done to rationalize the process of devising 
standardized exchange formats is a good thing.


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

Copyright 2001 XML.org. This site is hosted by OASIS