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

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 Thursday, 5 February 2004 15:51:35 UTC