OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: RE: [xml-dev] XQuery and DTD/Schema?

[ Lists Home | Date Index | Thread Index ]

At 04:40 PM 7/3/2002 -0400, Jonathan Robie wrote:
>Simon wrote:
>>So the named-typing mistake deepens.  Now that's unfortunate.
>Since this was the original message, I thought you wanted to say something 
>about named typing, which was the point of the message to which I 
>responded. You just said that you like RELAX-NG and DTDs a lot better than 
>you like XML Schema, but you haven't explained why you think named typing 
>is a problem or said much of anything about named typing.

Did you just completely miss the distinction between the structural typing 
that RELAX NG uses as a foundation and the creation of named types which 
lies at the heart of WXS?

>Let me try to explain why I think named typing is good. Here's a function:
>define function get-total( element invoice $i )
>   returns xs:decimal
>         sum( $i//item/price )
>This function assumes that the invoices it takes have been validated as 
>invoice elements according to some schema, and are not merely well-formed 
>elements whose name happens to be 'invoice'. At run-time, you don't want 
>to have to test every function parameter to see if it corresponds to a 
>schema, you simply want to ensure that the validator has said this 
>corresponds to the appropriate definition.

Right.  You're asking to make sure that the invoice corresponds to an 
arbitrary type named "invoice" which may or may not have any direct 
connection to the names of the elements and attributes therein.

To me, this is a bogus imposition of notions from other fields, seriously 
lacking respect for the kinds of flexibility that XML has to offer.  This 
makes perfect sense when I'm working with objects.  However, I don't 
believe that objects and XML have very many similarities, and that efforts 
to pretend XML is objects seem to lead us into minefields.

If I really wanted to make your:invoice into my:invoice, I've got a lot of 
options other than validation, many of which even work naturally with a 
structual understanding (elements and attributes) of XML rather than with 

>Named typing says that the validator indicates, with a type annotation, 
>that this invoice corresponds to a particular definition, and operations 
>that need to determine the type of an element need only look to see if the 
>appropriate type annotation is present. The opposite of named typing is 
>structural typing, which tests the entire structure. For XML, this is done 
>using structural subsumption.

You're adding your extra labels to the understanding of the XML document, 
and then you're expecting implementors to add support for that extra 
labels.  While the extra labels may be useful to you, in my mind it has 
nothing whatsoever to do with the XML.  The markup that was in the XML 
document - not the labels you've added through a schema - is a much more 
local explanation of what the contents of that document are supposed to be, 
and a much more explicit and safer foundation on which to build.

>Since you say named typing is a mistake, can you explain why you would 
>prefer structural subsumption to named typing for XQuery?

I don't think the kind of named typing you find so exciting is useful for 
the kinds of loosely-coupled applications XML is supposedly good for.

The kinds of named typing you find so useful work wonderfully inside of 
programs, but there are lots of reasons we don't typically communicate by 
sending Java classes back and forth.

I think you've mistaken a particular case that you find useful for a 
general case that is appropriate to XML, and I think you've forgotten that 
markup comes from a foundation where the information is often prior to the 
labeled structures - that people and programs actually go in and "mark up" 
documents on occasion.  I don't think the named type infrastructure you 
have to offer is anything more than inappropriate baggage.

XML ain't objects, and it ain't relational databases.  We'd be a lot better 
off looking at XML for what is, rather than forcing it to be what we want 
it to be.

Simon St.Laurent
"Every day in every way I'm getting better and better." - Emile Coue


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS