[xquery-talk] following-sibling and preceding-sibling

[Schochler, Rick (LNG-DAY)]

Thanks for the response. The absence of preceding and following sibling axes
strikes me as rather odd, if for no other reason than the fact that xquery
is being developed side by side with xpath 2.0 (and thus, I'd assume that it
would fully implement xpath functionality).

-----Original Message-----
From: Michael Kay [mailto:mhk at mhk.me.uk]
Sent: Thursday, July 10, 2003 6:48 AM
To: 'Schochler, Rick (LNG-DAY)'; talk at x-query.com
Subject: RE: [xquery-talk] following-sibling and preceding-sibling


> what is the logic/rational 
> behind the apparent restriction of left/right navigation? Is 
> there some other means of accomplishing this that I'm not aware of?

The XQuery WG has had this debate a number of times, and although there
are many people who would like to offer the full set of axes, we haven't
(so far) been able to sway the argument. But in the next draft, XQuery
processors will be *allowed* to offer all the axes, though not
"*required* to do so. So we-re making progress...

I find it difficult to state the arguments against offering all the
axes, since I find them unconvincing. The most common argument is that
it's difficult to optimize them - but then, it's even harder to optimize
the workaround that the user is forced to write if the axes aren't
available. Another argument is that they aren't needed - this seems to
come from people who have only ever encountered neat tabular XML that
maps directly to relational structures.

There is a simple workaround for following-sibling::x, you can write 

let $current := .
return ../child::x[. >> $current]

and similarly for preceding-sibling.

Michael Kay