W3C home > Mailing lists > Public > www-xpath-comments@w3.org > January to March 2001


From: Adam Van Den Hoven <Adam.Hoven@bluezone.net>
Date: Tue, 16 Jan 2001 16:22:44 -0800
Message-ID: <00BB1956AE40D411B5B60050DA27311F3C6029@mail1.bluezone.net>
To: "'www-xpath-comments@w3.org'" <www-xpath-comments@w3.org>
I've mentioned this on the XML-DEV mailing list recently so this may be
somehing you have seen.

I have been working on XSL transforms for the last six months or so and I
think there is something missing from the list of axes in the XPath spec.
While there are preceding-sibling and following-sibling axes, there is no
sibling axis (or a sibling-or-self axis but that may be too much). I totally
understand that I can accomplish the the effect of a sibling:: axis but I
wasn't thinking of actually using it at this point. The idea first came
about while reading a particular thread on the XSL list and I was simply
curious about why it wasn't included (Mike Kay suggested that nobody had
thought of it). 

The more I think about it, the more I think that it may be a useful axis to
have. I honestly don't know how XPath typically gets implemented but it
would seem that the predicate [sibling::node()/@role != self::node/@role]
would be easier to process than [preceding-sibling::node()/@role !=
self::node/@role and following-sibling::node()/@role != self::node/@role]
simply by viture of the fact that the first retrieves one node set and the
other does it twice.

There is also the case where you want to tell someone (like you see at
Amazon) "the majority of people who bought this thing also bought ...". A
part of the path that would be able to tell you these things might be:


or something more correct (I'm not sure you can mix the abbreviated syntax
with the full syntax but I'm going to do it for brevity). 

Lets say that I had the following Library.xml:
		<author>Adam van den Hoven</author>
		<title>A Really Groovy Title</title>
		<publisher>FooBear Press</publisher>
		<title>Neat Tips</title>
		<publisher>FireBug Press</publisher>
		<author>Adam van den Hoven</author>

I really don't care what order my nodes appear in (and if I assumed a
particular order, I would consider that poor programming) and it might be
indeterminant because I scrape the content from a number of different
sources and the tags aren't sorted. So if I wanted to know all the companies
that published my books I could use /library/book/publisher[../author =
'Adam van den Hoven'] or /library/book/publisher[preceding-sibling::author =
'Adam van den Hoven' or following-sibling::author = 'Adam van den Hoven'].
It may be faster (and IMHO more obvious) to use
/library/book/publisher[sibling::author = 'Adam van den Hoven']. That is
something an implementer would know better than I. 

Ok, the examples are a little contrived but I'm sure someone will find a
more relevant use case for it. The fact of the matter is, there are times
when you don't know where a particular node is relative to a node in
question making preceding and following meaningless. In these cases, it
would be a useful axis to have. 

> 		Adam van den Hoven
> 		Internet Application Developer
> 		Blue Zone
> 		tel. 604.685.4310
> 		fax. 604.685.4391
> Blue Zone makes you interactive.(tm) http://www.bluezone.net/
Received on Tuesday, 16 January 2001 19:31:51 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:02:14 UTC