- From: Michael Rys <mrys@microsoft.com>
- Date: Wed, 18 Feb 2004 08:30:36 -0800
- To: <jwrobie@mindspring.com>
- Cc: "Daniela Florescu" <danielaf@bea.com>, <public-qt-comments@w3.org>
> >[Michael Rys] You can achieve that functionality by explicitly
setting
> >your validation mode to strict. The issue is that many XML
applications
> >want to do validation as late as possible. Forcing XQuery
> >implementations to do so during every construction per default is the
> >wrong design (make more costly operations use explicit syntax).
> >
> >
> There is some merit to that argument. But another principle is that
the
> default behavior should not be surprising. Suppose the default mode is
> skip. I find it suprising that the following query would raise an
error:
>
> import schema "invoice.xsd";
>
> declare function total($i as element(my:invoice))
> as xs:integer
> {
> sum ($i//product/price)
> };
>
> let $t := <invoice>
> <customer>Wile E. Coyote</customer>
> <items>
> <item>
> <name>Atomic Hammer</name>
> <price>13.45</price>
> </item>
> <item>
> <name>Rocket Skates</name>
> <price>45.23</price>
> </item>
> </items>
> </invoice>
> return total($t)
[Michael Rys] I don't find this surprising. You are expecting an element
in a namespace but constructed an element without a namespace.
And if we use the interpretation of element(name) to basically mean any
element of the given name regardless of its schema association, then the
query would work fine assuming that you fix your namespace bug...
> I don't like your 'global' solution either, because the most important
> reason for SequenceType is stating the types of function arguments
and
> returns. It is rarely useful to specify that a function's argument be
> "any element whose element name is 'invoice', no matter what that
> element contains".
[Michael Rys] I disagree. I see many people interpreting element(name)
in this way and it seems much more intuitive. Note that for people that
use XML, often the element name is all that describes the type.
One problem of element(name), be it written as element(name) or the
current element(name,*) is that it looses the preciseness of the static
type when being passed untyped data. I think I have to raise another
comment about this...
> For instance, in the above query, what really
> matters to the function it that it knows how to find the price
elements
> within an invoice element - it is written based on assumptions about
the
> structure of the element, and the current element(my:invoice) makes
> precisely the right guarantees.
[Michael Rys] Finding the price element is the task of the /. As long as
the type allows the price, you should be able to find it. If you want
more precise type information, you can either specify element(global
invoice) or element(invoice, invoiceT). Neither of which is much more
complex and aligns better with the user's expectation...
> You suggest that we add more syntax to SequenceType (probably a bad
idea
> in general!) to distinguish the following cases:
>
> element(my:invoice) - any element named my:invoice
> element(global my:invoice) - a valid my:invoice element, as
defined
> in the ISSD
>
> I don't like that idea for a number of reasons:
>
> 1. Adding one more distinction to SequenceType is confusing for the
> user. I do not know enough important use cases for function parameters
> that specify the name of the element to make this the default for
> element parameters. This can already be expressed in our current
> syntax: element(my:invoice, xs:anyType)
[Michael Rys] This is not one more distinction. We already semantically
make that distinction (see schema context path) and is just a natural
extension of that concept.
Also, note that if you operate on untyped data and perform static
typing, element(my:invoice, xs:anyType) is useless, since it makes the
type to be too broad (everything now becomes xs:anyType and
xs:anySimpleType which will more often lead to static type errors).
> 2. There's no simple keyword that seems to suggest 'a valid element
> named my:invoice, as opposed to any element that simply has that
name'.
> Your suggestion to use 'global' for that is an indication of the
problem.
[Michael Rys] This sound like a non-sequitur. If find "global" to be a
simple keyword. Other proposals are to write element(/name) which has
the problem that the syntactic difference may be too small. Also note
that we use global in the validation context...
> 3. On average, about 80% of elements and attributes in schemas are
> locally declared, and 'global' implies not supporting valid, but
locally
> declared elements using SequenceType.
[Michael Rys] Your current semantics of element(name) also does not do
that. So what is your point about element(global name)?
> So I think this would be a bad idea.
>
> Jonathan
Received on Wednesday, 18 February 2004 11:31:10 UTC