RE: [xml-dev] Iceberg development (was Re: [xml-dev] maps)

["Mark Seaborne" <MSeaborne@origoservices.com>]

-----Original Message-----
>From: Jeff Lowery [mailto:jlowery@scenicsoft.com]
>Sent: 07 August 2002 18:54
>To: Mark Seaborne
>Subject: RE: [xml-dev] Iceberg development (was Re: [xml-dev] maps)


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

Indeed. In the days when I worked with EDI we had EDIFACT and message implementation guidelines as a starting point, and then lots and lots of test messages to see what was really happening. It always surprised me how many organisations have so little control over, or knowledge about, their inputs and outputs! 

I suppose I am wondering not so much whether formal and precise agreement is necessary, so much as when things get validated. I apologise for keeping harping on about EDI, but, when building business applications which were at least in part driven by EDI messaging it was never considered appropriate to expect the EDI parser to do more that check for valid structure (at least where I worked). A series of back end applications would take what had been expressed as EDI (or some other structure) and follow a formal ruleset to see whether the data actually made sense (i.e. appropriate combination of types with appropriate values).

Now EDI does have built in data typing, and if you wanted to you could build complex validation rules over many EDI parsers and I am sure many people have, possibly successfully. However, I found the approach of simple first pass validation of structure (ignoring as much as is practical of the data typing bit), probably followed by transformation into some application neutral, internal data structure, and only then worrying about data typing/validation/business rules, made things more manageable. 

So I quite liked the fact that DTDs concentrate on validation of structure, because that is the bit I am happy for the XML parser to handle on its own. XML Schema is a bit of a step backwards from my point of view because it bundles together validation of structure and content. I would prefer something (I don't know what) that allowed the formal expression of data/logical model validation rules, to which one can attach mappings to arbitrary physical representations (or visa versa). 

>....


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

I am not convinced that XML Schema does tie parties down sufficiently to be significantly more useful than the DTD. I have yet to see a schema (here at any rate) that would prevent parties from sending valid, utter rubbish to each other. Rather than increasing the complexity of XML Schema in an attempt to allow schemas to be more prescriptive, I would prefer to break up the problems of validation into more easily managed layers. But in principle, yes I agree that appropriate, formally expressed, machine processable, agreement ought to be useful.

All the best

Mark Seaborne