- From: Jonathan Robie <jwrobie@mindspring.com>
- Date: Tue, 17 Feb 2004 05:18:17 -0500
- To: Michael Rys <mrys@microsoft.com>
- Cc: Daniela Florescu <danielaf@bea.com>, public-qt-comments@w3.org
Michael Rys wrote:
>>Daniela Florescu wrote:
>>
>>
>>
>>>>Thus we would like to propose:
>>>>1. Make default validation mode to be skip
>>>>
>>>>
>>>Agreed.
>>>
>>>
>>By default, this would mean that a constructed element "foo" would not
>>match element(foo). I'm not at all sure that's a good idea.
>>
>>
>
>[Michael Rys] First, why is that a requirement?
>
>
Because elements are the only complex structure available to XQuery, and
when queries get large and complex, they need to be able to pass complex
structures around. It's like asking whether an object oriented program
should construct an object that is known to conform to its class
declaration by default, or whether C should create a struct that
actually conforms to its declaration by default. When the definition of
an element has been imported, by default, the elements that are created
should conform to that definition.
>Second, if we actually define element(foo) to mean any element with that
>name (and use something like element(global foo) to refer to elements in
>the schema context), then we could solve this problem in a more
>consistent and understandable way.
>
>
We have different understandings about what is consistent and
understandable. I teach a lot of workshops on XQuery, and we often write
modules like this:
module namespace my="invoice.xsd";
import schema "invoice.xsd";
declare function total($i as element(my:invoice))
as xs:integer
{
sum $i//product/price)
};
After importing a schema, users expect to be able to rely on the fact
that an invoice element actually has prices on it, that it conforms to
the definition found in the schema. This is a contract that allows the
programmer to assume a given structure. Users are surprised if they can
not rely on this contract. In addition to type safety, this also allows
useful optimizations for the system.
>>>>2. Remove Schema context from the spec
>>>>
>>>>
>>>Agreed.
>>>
>>>
>>I think this flies in the face of usage in documents governed by XML
>>Schema. Most elements are locally declared. When we did a serious
>>
>>
>count,
>
>
>>it was about 80% in the schemas we examined - we did this count
>>specifically to determine if this feature was needed. For an invoice,
>>
>>
>do
>
>
>>you really want to make it impossible to specify a customer element or
>>
>>
>a
>
>
>>product element as a function parameter? That's the kind of problem
>>
>>
>you
>
>
>>would get if you did this.
>>
>>
>
>[Michael Rys] I think for most of these cases, it is sufficient to know
>the name and the content type. So all you need is to use a named type
>(the element does not need to be globally declared). Educating people to
>write such schemata should not be a problem...
>
>
But the majority of element declarations are also anonymous, so there is
no name to use. We researched this very carefully when determining the
requirements for SequenceType.
I think that an XML query language needs to be able to query the XML
data that people are producing. If an XML query language requires people
to rewrite their schemas in order to be useful, I don't think we are
doing our job. The person writing the query is often not the same person
who is producing the data anyway, and it's not at all clear that we will
change the way people write schemas if we decide not to support the most
popular way of declaring elements.
>>>>3. Make support for validation modes lax and strict and the
>>>>
>>>>
>validate
>
>
>>>>keyword an optional feature.
>>>>
>>>>
>>>XQuery has already too many optional features (people are
>>>already complaining that it doesn't look like a standard)
>>>We should try to minimize them, not to add more of them.
>>>
>>>Could we tie it with schema import ?
>>>
>>>
>>I think tying it to schema import makes sense.
>>
>>
>
>[Michael Rys] As I pointed out earlier: I do not think so.
>
>
OK - I think we disagree here.
Jonathan
Received on Tuesday, 17 February 2004 05:20:52 UTC