Lists Home |
Date Index |
On Mon, 2002-06-10 at 17:25, Aaron Skonnard wrote:
> > Amelia A Lewis wrote:
> > > In XML, typing specifies validation algorithms.
> > Tim Bray:
> > Hmm... well it also allows software to unpack XML instances into
> > storage in a sensible way without being savvy to the internals of the
> > applications that generated or will use the data.
> > My question is, is there a need for this? -Tim
Good question. Both you and John Cowan specify that as a functionality
enabled by typing.
I don't understand it, though.
How does typing something as Notation, as NCName, as gMicrosecondEon, or
as unsignedLong help me to unpack an XML instance into Java native
storage without knowledge of semantics?
I pick those primitive/built-in simple types specifically, because they
don't map intuitively to any Java primitive that I can think of, which
means that the mapper from XML type to language-native type is going to
be highly dependent upon language, parser implementation, and other
significantly complex locally-defined details.
Using XSDL means that we have to agree on how to handle these types,
even if gLunarcycleHour isn't relevant to what we're doing. More to the
point, validation is a "lower level" than conversion to native type, if
conversion to native type is a proper function of XML modules at all.
> It also facilitates the reverse scenario: exposing strongly-typed data
> (database, object graph, whatever...) as an Infoset, which can be
> processed using any of XML's layered services (XPath, XSLT, XML Query,
> etc.) in a natural way. The demand for such functionality seems to be
> growing as businesses see it simplifying the server integration story.
Umm, I'm working for an EAI vendor, as part of the SOAP team. This is
usually regarded, by the folks I'm in regular contact with, as either a
really pleasant opium dream, or a surprisingly thorny briar patch,
however beautiful and fragrant its flowers.
So I'll reiterate: the primary story for typing in XML is for
validation. XML Schema, DTD, and Relax NG all provide mechanisms for
structural validation (validation of the coarse-grained content of
elements). The introduction of data types for "simple" (text nodes and
attributes) nodes provides a way to validate the text, beyond existing
parsed character data (the only valid type for text nodes in DTD),
CDATA, Name, Token, NCName, QName, ID, IDREF, and the derived list
types. Note that the attribute types are almost exclusively concerned
with reference types (XML versions of pointers), and that at least two
of them actually embed co-occurrence constraints (ID and IDRef), which
cannot be modeled in any of the current schema languages, except by deus
So I'd suggest that XSDL's attempt to produce a universal system isn't a
success, and that the first thing to begin with is to define the minimal
role of typing in XML. Perhaps it's possible to move conversion from
the application into XML (although I still don't quite understand how
one is going to map, for instance, signedInt into perl or python without
writing a specialized constraint handler of some sort, which effectively
puts it back into the application), but I don't think that this should
be the focus of simple type definitions. If it's supposed to be, then
the type definition probably ought to include the target language or
languages. And in any event, validation of primitive types is the first
step to actually doing the conversions, and specifies the *XML content*,
rather than per-language conversion APIs.
Amelia A. Lewis email@example.com firstname.lastname@example.org
A hundred thousand lemmings can't be wrong.
This is a digitally signed message part