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

You conceptually loop exactly the same amount, so the optimizations may
find ways to optimize and rewrite either.

And I have the same concern about the overloading of the semantics that
Mike has.

Best regards
Michael

> -----Original Message-----
> From: public-qt-comments-request@w3.org [mailto:public-qt-comments-
> request@w3.org] On Behalf Of Sarah Wilkin
> Sent: Friday, February 06, 2004 9:50 AM
> To: Michael Rys
> Cc: public-qt-comments@w3.org; Michael Kay
> Subject: 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 15:29:56 UTC