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