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

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

>-----Original Message-----
>From: Simon St.Laurent [mailto:simonstl@simonstl.com]
>Sent: 06 August 2002 19:47
>To: xml-dev@lists.xml.org
>Cc: vdv@dyomedea.com
>Subject: RE: [xml-dev] Iceberg development (was Re: [xml-dev] maps)


>Instead of describing these things as "X is of type Y", I'm thinking it 
>might be easier to define the value space through a transformation from a 
>lexical representation to a set of values which may or may not involve an 
>explicit cast operation.  I'm much happier saying "treat X as of type Y for 
>this operation" - that leaves a lot more flexibility and room for fallbacks.

In a similar vain, in the days when I worked with EDI, I once contemplated, but never got round to writing, some software to allow you to describe one physical message as if it were another. So company X could describe its comma delimited flat files as if they were EDIFACT orders. My parser could then be set up to look at rules which might say, if anything purporting to be an order from X arrives, just parse out the order number, and send it back, but this time described as an EDI order response from company Y (because we know that company X always orders the same things in the same quantities). Obviously, by description, I mean mapping. In the XML world, XSLT does the job.

I met a guy last year who works for a company that makes its living translating the typed data in requests for quotes from manufacturers of finished goods to component makers. The requests contained a lot of technical information about the characteristics of the materials to be used in manufacture, but were often expressed in different terms (e.g. different units of measure, even different concepts) to those used internally by the component maker, so a formal, mapping from one to the other was needed. With the mapping in place, both sides were happy, because each carried on using data types appropriate to their own domain. 

So "treat X as Y" is good, whether X is a primitive or complex type. The hard thing, as others have said, is not so much saying that this piece of data is of type integer, or whatever, but saying it in a way that is context sensitive, so that one can do something useful with it. In the area I work in (message standards for UK insurance industry), prose message implementation guidelines (MIGs) fulfil this function. They express all the typing/validation/usage scenario information that cannot be handled by XML Schema (e.g. this date should be in the future, but not too far in the future; this date is a date of birth of somebody who could potentially still be living).

I resent spending long hours working on XML Schema schemas, when I know that all the schema can really do is give an extra hint to an application that an instance of a document is, or is not, corrupt. DTDs are pretty much as useful, and are quicker to churn out.

When XML was young, and had only the DTD to validate against, 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. 

Experience of writing software to handle EDI messages has taught me that such a separation works well, at least in the context of data transformation. I.E. don't mix transformation of physical and arbitrary structure with transformation of context and meaning - it makes things confusing. It is one reason why I like XSLT. It concentrates its efforts on transformation of structure, and encourages one to transform content in another layer.

All the best

Mark Seaborne

Origo Services Ltd