[
Lists Home |
Date Index |
Thread Index
]
At 04:59 PM 7/3/2002 -0400, Simon St.Laurent wrote:
>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?
I was quite aware of that, as my messages implied. But your message didn't
seem to be discussing structural typing at all!
Incidentally, XML Schema has aspects of both named typing and structural
typing - it uses structural comparison to create the type properties in the
PSVI, which can then be used as the basis for named typing. It would be
quite feasible, I think, to define type annotations for RELAX-NG. In order
to map into the XQuery/XPath data model, it would have to.
>>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.
Let's ignore objects and relational data, and concentrate on named typing.
XML is flexible, but the whole concept of validity for XML is that there is
a contract between the producer and the consumer of the information, and
that a validated instance is shown to conform to the contract. This is not
a foreign concept in XML, and has been there since the very beginning.
>>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.
I find this very odd. Validation says that the producer and the consumer of
the information expect the XML to conform to a particular definition. I am
asking a conforming XML Query processor to know the definition that was
used to validate. Is that so strange? This definition tells me whether a
series of digits should be sorted as an integer or as character data, and
allows queries to give the correct result. Why is it wrong to ask for an
XML Query processor to preserve type information?
>>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.
Are you asking me to drop typing, or just named typing? Both RELAX-NG and
XML Schema support the notion of types - is that wrong? Named typing allows
me to know, at run-time, that a validator has said my data conforms to a
particular definition. That's pretty important, because otherwise my
processing may compute completely incorrect results.
Typing is also useful for complex types. Suppose I compute the total for
the items on an invoice - but on one instance, the element is named
something other than "item" - my query would simply compute the wrong
answer. Why is that of benefit?
>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.
Strawman alert! XQuery is *not* object oriented, and it is not relational.
Nobody is saying that named types are sent back and forth, or suggesting
that XML instances should be Java objects.
The type annotations are added when an instance is processed by the query
processor, or often when an instance is loaded into a persistent store.
Many people validate XML, and many people do this with schema languages
that support types. What is wrong with saying that a query processor must
know how to keep track of type information? Since named typing is one of
the simpler and more efficient ways to do this, what's wrong with using
named typing? What alternatives do you suggest?
>I don't think the named type infrastructure you have to offer is anything
>more than inappropriate baggage.
How do you suggest XQuery should locate the type information associated
with an instance?
>XML ain't objects, and it ain't relational databases.
I certainly agree.
>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.
I agree, but I do believe that XML should be able to express datatypes -
and a lot of people seem to agree, including the designers of RELAX-NG and
most other recent schema languages. I would like to be able to support
these datatypes efficiently.
Are you asking us to drop support for types entirely? If so, is that
because you want all processing to be done by converting XML into Java or
relational data first, or because you think processing data does not
require types? Or are you suggesting a different strategy for supporting
types in XQuery? If the latter, could you please explain what approaches
you favor?
Jonathan
|
