RE: [Xquery] 3.9 Ordered and Unordered Expressions

Thanks David. You may or may not be aware that there is a conversation going
on about this topic on the internal xsl-query list at the moment.

Michael Kay 

> -----Original Message-----
> From: public-qt-comments-request@w3.org 
> [mailto:public-qt-comments-request@w3.org] On Behalf Of David Carlisle
> Sent: 02 August 2004 10:54
> To: public-qt-comments@w3.org
> Subject: [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 07:19:04 UTC