XML and embedded compound data types (was "Why XML data typin is hard")

[Paul Prescod]

Gabe Beged-Dov wrote:
> 
> The perspective is the possibly naive one that XML can/should be used to
> capture ALL of the structural aspects of a complex tree of data. Wherever a
> compound type occurs in the source data, it should be mapped to a
> corresponding compound type in XML.  

What is the "source data?" XML is a language description tool. It is not a
database serialization tool. In many cases the "source data" is my head.
XML happens to be useful as a database serialization tool because
databases are simpler than the stuff I have in my head.

> A key heuristic to see if this approach
> is being adhered to is to see if any attribute  values or character data
> requires additional parsing by the application in order to deserialize
> additional structure.

XML allows us to design languages that are palatable for human beings.
That is its only technical advantage over an S-Expression-based
equivalent. You can remove the "flaw" of human orientation by requiring
everything to be explicitly expanded, but you will also destroy XML as a
language. It will be as unreadable and untypeable as its competitors and
will be ignored just as they are.

Just out of curiousity, here are some of the XML-related specs that fail
according to your heuristic:

 * XPointer
 * XML Namespaces
 * XSL

and of course any specification built *on top* of these.

 Paul Prescod  - ISOGEN Consulting Engineer speaking for only himself.
 http://itrc.uwaterloo.ca/~papresco

Christmas shopping in a T-Shirt? Toto, I have a feeling we 
aren't in Canada anymore.

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)