Re: RE: [XQuery] 3.2 Order of nodes constructed in a path

This relates back to the other problem of only nodes being allowed for 
E2 in E1/E2. Currently 
the only way to get the value of context functions such as position() 
and last() is to create a 
new node, as in E1/text{position()}. If constructed nodes are disallowed 
then retrieving these 
values involves more work than it should.

Further, it seems unnecessarily complicated to allow user functions 
within a path that return 
a manipulation of the input nodes but not allow ones that return newly 
constructed nodes.

--Sarah

---------Included Message----------
>Date: Wed, 04 Feb 2004 23:33:22 -0800
>From: "Michael Rys" <mrys@microsoft.com>
>To: "Michael Kay" <mhk@mhk.me.uk>, "Sarah Wilkin" <swilkin@apple.com>, 
<public-qt-
comments@w3.org>
>Subject: RE: [XQuery] 3.2 Order of nodes constructed in a path
>
>I think we should simply disallow constructed nodes inside path
>expressions. But I am not sure how we can do this without having to
>extend the semantic framework.
>
>Best regards
>Michael
>
>> -----Original Message-----
>> From: public-qt-comments-request@w3.org [mailto:public-qt-comments-
>> request@w3.org] On Behalf Of Michael Kay
>> Sent: Wednesday, February 04, 2004 1:53 PM
>> To: 'Sarah Wilkin'; public-qt-comments@w3.org
>> Subject: RE: [XQuery] 3.2 Order of nodes constructed in a path
>> 
>> 
>> Sorry to go off at rather a tangent, but I would love to have a rule
>> that limited the ability to create new nodes within a path 
expression.
>> 
>> It used to be true in XSLT that XPath expressions were side-effect
>free.
>> We now have this limited side-effect of creating new nodes, which is
>> possible even in XPath, because XPath expressions can call XSLT
>> functions that create new nodes. This greatly complicates the
>semantics
>> and makes life a lot more difficult for optimizers, without actually
>> providing any benefits to users. It just means we have to spend a 
lot
>of
>> time discussing pathological cases like the one you raise; we should
>> find a way to ban these.
>> 
>> It's tricky to define such a rule but I think it could be done, by
>> additions to the dynamic context.
>> 
>> Michael Kay
>> 
>> 
>> > -----Original Message-----
>> > From: public-qt-comments-request@w3.org
>> > [mailto:public-qt-comments-request@w3.org] On Behalf Of Sarah 
Wilkin
>> > Sent: 04 February 2004 21:14
>> > To: public-qt-comments@w3.org
>> > Subject: [XQuery] 3.2 Order of nodes constructed in a path
>> >
>> >
>> >
>> > Currently the order of nodes constructed in a path is undefined 
for
>> > many cases. For example:
>> >
>> > let $source := <foo><a>1<a>2</a></a><a>3</a></foo>
>> > return $source/element bar { .//a/element b { text() } }
>> >
>> > will return a variation of
>> > <bar><b>1</b><b>3</b><b>2</b></bar> with the
>> > "b" elements in an undefined, but stable, order. From 2.3.1 
Document
>> > Order: "The relative order of nodes in distinct trees is stable 
but
>> > implementation-dependent, subject to the following constraint: If
>any
>> > node in tree T1 is before any node in tree T2, then all nodes in
>tree
>> > T1 are before all nodes in tree T2."
>> >
>> > We feel this is unsatisfactory for embedded node creation;
>> > the order of
>> > created elements should be the same across implementations
>> > (and runs on
>> > the same implementation). One simple fix is to base the
>> > document order
>> > of new nodes in a path on their position. However, this brings up
>> > problems where the position repeats. For example:
>> >
>> > let $source :=
>> > <source>
>> > 	<foo><a>1<a>2</a></a><a>3</a></foo>
>> > 	<foo><a>4<a>5</a></a><a>6</a></foo>
>> > </source>
>> > return $source/element bar { .//a/element b { text() } }
>> >
>> > Would end up with nodes 1 and 4 appearing before elements 2 and 5.
>We
>> > would appreciate any input on this issue.
>> >
>> > --Sarah
>> >
>
>
>
---------End of Included Message----------

Received on Thursday, 5 February 2004 14:23:08 UTC