- 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