[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: xpath axes

• From: Adam Van Den Hoven <Adam.Hoven@b...>
• To: "XML Development Mailing List (E-mail)" <xml-dev@l...>
• Date: Tue, 16 Jan 2001 16:12:16 -0800

Andrew wrote:
> I am not sure I grasp your point.
> You want something additional to the 
> following-sibling::
> or
> previous-sibling::
> axes mentioned in Section 2 of the XPath Recommendation?

That is exactly my point. I totally understand that I can accomplish the the
effect of a sibling:: axis (as Ken pointed out) 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. 

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:

/Invoices/Invoice/Item[@partNo='sku2']/sibling::Item

or something more correct. 

If I had the following Library xml
<library>
	<book>
		<author>Adam van den Hove</author>
		<title>somehting</title>
		<publisher>FooBear Press</publisher>
	</book>
	<book>
		<title>Neat Tips</title>
		<publisher>FireBug Press</publisher>
		<author>Adam van den Hove</author>
	</book>
</library>

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 book 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'], but it
may be faster (and IMHO more obvious) to write
/library/book/publisher[sibling::author = 'Adam van den Hoven']

Ok, both 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 so
preceding and following isn't always meaningful. In these cases, it would be
a useful axis to have. 

• Prev by Date: Re: 4Suite Server 0.10.1
• Next by Date: The Aftermath (was Re: 4Suite Server 0.10.1)
• Previous by thread: Re: xpath axes
• Next by thread: XPointer syntax
• Index(es):
  • Date
  • Thread