W3C home > Mailing lists > Public > public-qt-comments@w3.org > August 2004

RE: [Xquery] 3.9 Ordered and Unordered Expressions

From: Michael Kay <mhk@mhk.me.uk>
Date: Mon, 2 Aug 2004 12:18:24 +0100
To: "'David Carlisle'" <davidc@nag.co.uk>, <public-qt-comments@w3.org>
Message-Id: <20040802111904.27DE7A111B@frink.w3.org>

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
> 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

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:45:20 UTC