RE: [XQuery] MS-XQ-LC1-124

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

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

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

[Michael Rys] This does not negate my proposal to write your semantics
of implicit schema lookup in a slightly different way:

   module namespace my="invoice.xsd";
   import schema "invoice.xsd";
 
   declare function total($i as element(global my:invoice))
     as xs:integer
   {
      sum $i//product/price)
   };
 
[Michael Rys] This is only one token more and seems much more intuitive
to any reader of the function (namely that we look the type up in the
ISSD).

> >>>>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 19:58:13 UTC