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

[Gabe Beged-Dov]

I have been reading the latest postings on XML data typing and want to throw
out a different viewpoint. several caveats are that I haven't perused all of
the archives to see if I'm tramping down well-worn paths. I am also much
more interested in the non-prose uses of XML so take that into account.

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

In the case of a date or float, I would argue that they are both compound
types and should be represented as such. If this approach is chosen, you can
end up using integers and enumerations (as long as you use attributes). This
is obviously much more verbose, but cleanly separates content from
presentation. I forget which of the many schema proposals used this approach
but at least one did.  If you adhere to this approach, alot of the issues of
providing inline support for validation of character data (that will require
additional parsing by the application) goes away.

Many issues of data typing remain, such as how to recognize a valid country
name, but these are not structural issues related to compound types hiding
inside a human readable serialization  format.

Gabe Beged-Dov
www.jfinity.com





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)