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] Iceberg development (was Re: [xml-dev] maps)

[ Lists Home | Date Index | Thread Index ]

> -----Original Message-----
> From: Mark Seaborne [mailto:MSeaborne@origoservices.com]
> ...
> I was told (at least I think I was told): XML is just text, 
> it is primarily for exchange of structured data, it doesn't 
> need data types because applications at either end of the 
> wire already handle typing; let XML handle the structure, and 
> code at the end points handle the rest. 

How'd you get those endpoints to be able to exchange untyped data without
hiccupping? Tacit understanding? Verbal agreement? Narrative specification?
Formal schema language?

If it's the last (and that would be the least ambiguous), then how do you
know that the data you're exchanging is valid according to the schema? It
doesn't matter that the two internal data models (yours and mine) are
completely different. You can do whatever you want with the data I hand you;
it's your responsibility to determine that the values compatible with the
agreed to (data exchange) schema have mappings to your internal data model.
I don't care what you do with the data, all I care is that I hand you no
surprises. 

Regular expressions help: they add microstructure, if you will.  They don't
add semantics. But there there may not be an accurate lexical representation
of, say, the following:

1) all prime numbers
2) PI
3) reals in  the range +/- 10.13E20
4) Fibonacci numbers

I may intend to pass you, say, a constant PI. It may be a numerical
approximation of arbitrary precision, or it may just be a symbol. You can do
what you want with that, treat is as character data and make it a "cherry
PI" if you wish, I don't care. But I personally cannot violate the contract
that is represented by the schema.  I'm stuck with handing you PI values,
approximate or symbolic, not "cherry" or "apple PI" values. Your app might
choke if I did.

I've seen too many 400+ page mostly narrative specification of data models
that different vendors interpret differently. A schema gives vendors less
wriggle room for interpretation, expecially if that schema can be used for
automated validation.  I'm all for the Iron Fist of Formality when it comes
to data models, including those expressed in XML. Guess I'm just funny that
way.




 

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

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