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

Received on Thursday, 5 February 2004 02:33:26 UTC