[
Lists Home |
Date Index |
Thread Index
]
I just want to emphasize this sentence from Uche's post.
"As soon as you start to inject the welter of all these other systems into the foundation of XML, you lose this facility, or more precisely, as the Schema group did with their data types, you invent yet another different and incompatible type system."
-----Original Message-----
From: uche.ogbuji@fourthought.com [mailto:uche.ogbuji@fourthought.com]
Sent: Tue 5/7/2002 7:33 AM
To: Matthew Gertner
Cc: 'Elliotte Rusty Harold'; xml-dev@lists.xml.org
Subject: Re: [xml-dev] XPath 1.5? (was RE: [xml-dev] typing and markup)
> Admittedly I am just restating the problem, but I am curious to know why you
> are so convinced that the data in XML documents are strings that can be
> translated into other data types when necessary, and not dates, number, etc.
> that are serialized as strings when an XML document is instantiated. The
> counterargument, which strikes me as extremely compelling, is that
> practically every environment *other* than an XML document would benefit
> from explicit use of the underlying datatypes. This includes storage
> engines, user interfaces (where formatting, localization and type/range
> checking must occur), most popular programming languages, etc. I can
> certainly say from my experience programming in Java and C++ that I would
> prefer for a number to be a number and for a date to be a date, rather than
> having to constantly convert back and forth.
Elliotte has this one exactly right, IMO.
It is precisely the fact that every programming language, platform, tool, DBMS, etc. out there has a different and usually mutually incompatible notion of core data types that makes it valuable that XML is grounded in text.
This divorces data expressed in XML from physical representation issues (save Unicode), and I think it is the single most significant reason for XML's success as an integration tool.
As soon as you start to inject the welter of all these other systems into the foundation of XML, you lose this facility, or more precisely, as the Schema group did with their data types, you invent yet another different and incompatible type system.
As Elliotte puts forth, XML should support whatever representation of thier data structures a programmer wants, but in an inert capacity. It is up to the programmer to impose the desired view on what is lexically expressed in XML in a separate layer. XML tools should provide *generic* facilities for facilitating this view, and not facilities that are wedded to any construction of the value space. Not that of Java, not that of SQL, not that of XSDL. All these should be imposed in a modular fashion, if the user requires it.
And lo! This would have the amazing side-effect of keeping the core of XML technologies relatively simple. Wasn't this the point of the whole exercise of XML in the first place?
--
Uche Ogbuji Fourthought, Inc.
http://uche.ogbuji.net http://4Suite.org http://fourthought.com
Track chair, XML/Web Services One (San Jose, Boston): http://www.xmlconference.com/
DAML Reference - http://www.xml.com/pub/a/2002/05/01/damlref.html
RDF Query using Versa - http://www-106.ibm.com/developerworks/xml/library/x-think10/index.html
XML, The Model Driven Architecture, and RDF @ XML Europe - http://www.xmleurope.com/2002/kttrack.asp#themodel
-----------------------------------------------------------------
The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
initiative of OASIS <http://www.oasis-open.org>
The list archives are at http://lists.xml.org/archives/xml-dev/
To subscribe or unsubscribe from this list use the subscription
manager: <http://lists.xml.org/ob/adm.pl>
|
