ISSUE: Misalignment between types and paths

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