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

In our typical usage scenarios it is very common to grab all of the 
text from a path and manipulate it in some way. For example:
string-join(doc("foo.xml")//text()/local:do-something(.), ",")

It feels natural to write the query like this instead of having a 
second loop. Perhaps more importantly, it means on the implementation 
side we only loop once instead of twice.

--Sarah

On Feb 5, 2004, at 12:51 PM, Michael Rys wrote:

> I still don't understand why it is so bothersome to have people write:
>
> for $i in E1 return E2($i)
>
> if E2 is an expression that produces atomic values.
>
> Your two examples below have to be rewritten using at and count, but I
> find it hard to see usecases to return position() or last() in the way
> you specify below.
>
> Best regards
> Michael
>
>> -----Original Message-----
>> From: swilkin@apple.com [mailto:swilkin@apple.com]
>> Sent: Thursday, February 05, 2004 11:15 AM
>> To: Michael Rys
>> Cc: Michael Kay; Sarah Wilkin; public-qt-comments@w3.org
>> Subject: 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 Friday, 6 February 2004 12:49:32 UTC