ISSUE: please provide alternative '/' operator

Summary: The implicit semantics of '/' are unpleasant in many
          circumstances.  Please provide an alternative shorthand
          operator that does simple projection.


The slash (/) operator in XQuery is currently defined to be compatible
with XPath 1.0.  In particular, it doc-sorts and duplicate-eliminates
its result.

This is a good operator in many circumstances (particularly when
working with documents rather than data), and XPath compatibility is
vital for XQuery's acceptance.


However, there is also a need for a NEW, simpler operator (I propose
it be spelled '\'), that is just a shorthand for the 'for' statement
with an implicit range variable.

This would deal with the cases in which you are dealing with
specially-sorted data (as the gotcha in the spec notes), or when for
other reasons you wish the result not be sorted and
duplicate-eliminated.

This alternate operator could also lift the restriction that both
sides of the expression must evaluate to sequences of nodes.

Note that some operator other than '\' could be proposed if it is not
liked.  '->' springs to mind immediately as implying projection.



It would greatly improve the readability of certain sorts of queries
that will be quite common in many situations.

    ($employees sortby @salary)\spouse\@name

would get the names of all employees' spouses, sorted by employee
salary (perhaps for giving gifts?).

Not providing such an operator will make many queries (like the above)
needlessly verbose:

    for $x in $employees sortby @salary return
      $x/spouse/@name

which is dramatically less concise and pleasant.



I also liked, in earlier specs, the power to be able to apply
functions to lists easily:

    ("giraffe", "elephant", "cat") \ xf:string-length(.)

would retrieve a list of the lengths of the strings, in order.  This
provides concise syntax for very powerful and useful functionality.



This operator also allows convenient extraction of nodes in much more
interesting ways.

    ("203", "116")\id(.)\@name

retrieves the names of elements with ids '203' and '116'.



A simpler projection operator would be much more understandable and
predictable to users of XQuery that do not come from an XPath
heritage.  Less implicit behavior is more understandable.  The simpler
projection operator is easily explained as being identical to a 'for'
expression, and just syntactic sugar.  XPath '/' comes from an older
heritage and does a number of things that seem surprising at first.


A simpler projection operator is strictly more optimizable, as it has
less behavior.  It is certainly easier to optimize, and the compiler
doesn't have to do clever tricks (that may fail in edge cases) to
avoid doing sorts and duplicate removal all the time.


It is possible that interactions between the XPath projection and the
simpler new projection operator would be confusing.  Note that,
however, as long as a '/' does not appear after any projection
operations, no ordering issues arise.

In any case, compilers should issue a warning in cases where '/' is
used in ways that may destroy user-specified ordering.  This problem
does not arise through the introduction of a new operator: sortby
already has this problem, as do many other language features.


In summary, I propose that a simple projection operator be added, and
made a simple shorthand for a FLWR expression with an implicit range
variable.  This will make many queries more concise, particularly
those that deal with specially-sorted lists and those that work with
sequences of simple-typed values.  It would also provide very simple
idioms for performing complex and powerful operations.



Thank you for your time.

       -Shawn Vincent.


--
Shawn Vincent, svincent@exalt.com
Exalt Inc.

Received on Monday, 14 January 2002 10:33:34 UTC