- From: Shawn Vincent <svincent@exalt.com>
- Date: Mon, 14 Jan 2002 10:39:02 -0500
- To: XQuery Comments <www-xml-query-comments@w3.org>, Shawn Vincent <svincent@exalt.com>
Summary: There is a misalignment using Schema types and XPath element names. XQuery inherits path expressions from XPath 1.0, which was not a Schema-aware language. This creates a misalignment between the specification of the types of data in XQuery generally (function parameter types, typeswitches, etc), and the specification of types of data when selecting it (element names). --- To illustrate what I mean, assume that I have a schema that defines an element type. ... <xs:element name="Person"> ... </xs:element> ... I could write a function that takes one of these persons as a parameter. define function process-person (element of type Person $person) { ... } Using it, I may reasonably want to do something like this: for $x in $organization//Person return process-person ($x) But wait! That isn't right. The 'for' expression here is selecting all element descendents of the $organization node that have 'Person' as their NAME. Not their TYPE. In addition to being confusing and wrong, this example also has problems, for example, if there are other elements (perhaps local ones) with different types that also have name person. You could do this instead: for $x in $organization//.[. instance of element of type Person] return process-person ($x) which is correct, but incredibly ugly, verbose, and difficult to optimize (as having ad-hoc tests for type here may be of many different forms, many difficult to recognize). The verbosity wouldn't even be so bad if people weren't expected to do queries like this. If it were ok to use the syntax for which there is a shorthand (element name tests), then there would be no problem. However, it seems odd that in a language that is trying to use schema as its type system, with schema types everywhere in the language, that an ENTIRELY DIFFERENT mechanism would be used for actually *selecting* the data to pass into the typed parameters, store in the typed variables, etc... Using element names in paths also creates issues: 1. static typechecking has more heavy lifting to do, and less can be known at compile time. 2. it is confusing to the user to have multiple ways of referring to the type of same data that must be used in different circumstances. 3. element name tests do not take into account element subsitution groups, which means that for many schemas, there is not currently any pleasant syntax for extracting elements at all! --- I propose an extension to the path expression syntax that allows one to test node types as well as node names. There is already precedent for this: a number of node type tests are already in XPath 1.0 (node(), element(), attribute(), comment(), etc...). It would be good to extend these with the addition of 'type(Datatype)'. This would allow the use of expressions such as: for $x in $organization//type(element of type Person) return process-person ($x) which is at least more concise syntax. It also has the advantage that it seems like a mechanism you are actually supposed to use, and will encourage users to make more type-safe queries. It is still too verbose, however. I also propose (although with less hope of acceptance), that a shorthand syntax be usable in the above case (that of selecting elements of a particular type). The syntax I propose as a strawman is '~', used in the same way as '@' is for attributes. In this subproposal, the above example could be written as: for $x in $organization//~Person return process-person ($x) which isn't much more verbose than for $x in $organization//Person return process-person ($x) and is actually nice to use. --- In summary, I claim that using element name tests to extract data and type tests everywhere else in the language is inconsistent, and have proposed two extensions to XQuery to rectify the situation. This proposal makes more sense to the user, is easier to statically typecheck, and adds a level of consistency to XQuery. Thank you for your time. -Shawn Vincent. -- Shawn Vincent, svincent@exalt.com Exalt Inc.
Received on Monday, 14 January 2002 10:37:12 UTC