[Xquery] 3.9 Ordered and Unordered Expressions

A query about the semantics of unordered.

Firstly a comment that unordered{} does seem very strange. Xpath 1 had a
very elegant model for unordered collections of nodes: "node sets"
which was jettisoned in Xpath2/Xquery for ordered sequences, and now
unordered collections apparently need to have been brought back in
this rather ad hoc mechanism of "implemenation defined" ordered
sequences.

However leaving that aside, my real comment is about the notes in 3.9


  The fn:unordered function can operate on any sequence, whereas an
  unordered expression affects the ordering only of node sequences (not
  sequences of atomic values).

This does not seem to follow from any of the previous discussion of
unordered{} where it is described as applying to Path expresions and
FLWOR. 

so 

unordered {for $i in  1 to 10 return $i}

would (without this note) apparently be legal and be some permutation of
1 .. 10.

If this comment is intended to be a normative constraint rather than a
descriptive summary of an earlier definition it should probably be
phrased differently. Also it only mentions node sequences (affected)
and sequences of atomic values (not affected) and doesn't say what
happens about mixed sequences of nodes and atomic values. Whether
mixed sequnces are or are not affected by unordered{} it seems that
a system can't know (if its not using static typing) until it has
constructed an entire sequnce whether it is a node sequence or an
ataomic sequence or a mix, and so it can't know whether unordered{}
applies until after it has constructed the whole sequence which probably
interferes with much of the optimisation gains that one might hope to
have.



   In a region of the query where ordering mode is unordered, certain
   functions that depend on the ordering of node sequences may return
   nondeterministic results. These functions include fn:position, fn:last,
   fn:index-of, fn:insert-before, fn:remove, fn:reverse, and
   fn:subsequence

This note is I think misleading as it implies something special about
"certain" functions. In fact _all_ functions that (potentially) return
a sequence of 2 or more items are affected by unordered{}, as 
a function call is a path expression.

PathExpr
  RelativePathExpr
    StepExpr
      FilterExpr
       PrimaryExpr 
          FunctionCall 



   For example, in an ordered region, the path expression //a/b[5] will
   return the fifth qualifying b-element in document order. In an
   unordered region, the same expression will return an
   implementation-dependent qualifying b-element.


implies that //a/b[5] will typically just return a single b node "_the_
fifth" but of course it will normally return many b nodes, the fifth b
child of each a. When unordered{} is in effect it will return one b
child for each a that has 5 or more b's, but which b's are returned, and
in which order, will be unspecified.



David


________________________________________________________________________
This e-mail has been scanned for all viruses by Star Internet. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, visit:
http://www.star.net.uk
________________________________________________________________________

Received on Monday, 2 August 2004 06:28:56 UTC