OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] Quick Xpath

[ Lists Home | Date Index | Thread Index ]

On Wed, 2002-07-17 at 23:43, bob mcwhirter wrote:
> > > Howsabout given:
> > > 
> > > 	(//foo | //bar)[4]
> > > 
> > > Would that be the 4th occurrence of either foo or bar, in document 
> > > order?  That's just an implementational nightmare.
> > 
> > I don't see it as an implementation nightmare at all, having implemented 
> > XPath.  Yes it would probably be a nightmare for the user, but so would:

Hmm.  It was explained to me not as the set having an order, but that
each node in the set has, effectively, a property indicating "location
in the tree," and that thus the apparent ordering of the node-set is an
emergent property.

> Efficiency-speaking, it's a nightmare.  At least the only solution I've come
> up with includes walking the entire tree in order to determine the relative
> (possibly interleaved) order of your foos and bars.  I guess the argument
> is that //x walks the whole tree anyhow, and maybe you could do something
> intelligent.

If you do that, and you can somehow (*sigh*, this is Java, where access
to addresses is somewhat problematic) extract the address of each
object, that address should be a unique reference, thus suitable as a
hash key, and the node-order could be stored externally to the tree, as
a decoration of the hash-set (you wouldn't need to hash every node in
the tree, just the ones in the node set; the value might be an array of
integer indicating position).

> fwiw, sure, if the tree was unchanging and the tree-builder was kind enough

Umm, for the purposes of XPath, can't the tree be regarded as
unchanging?  If the user is going to extract a node-set based on an
XPath expression, then change the tree in a fashion that affects the
returned node-set, then investigate the node-set ... seems to me
equivalent to ConcurrentModificationException.  "It doesn't work when I
free() twice!"  Proper response is not to fix it, but to advise user not
to do that.

> to enumerate the nodes for us, then ordering wouldn't be a pain.  But, for
> jaxen, since we support k different object models, the assumptions we can
> make are weak, as best.  

Generally speaking, though, if you have to iterate over the whole tree,
then you should be able to supply a simple array of positive integer
indicating level and sequence in level, regardless of whether the
underlying abstraction supports it (that is, the degenerate XPath
expression /1/3/7/2 should uniquely identify a node (but not an
attribute or namespace declaration node; slight complication to handle
those, and they don't actually *have* order among themselves (that is,
sibling attributes of a given parent element have no relative order)),
and can easily be represented by the array { 1, 3, 7, 2 }).  Determining
relative order within the document from this positional array is
relatively easy, and if it were stored at the time of creation of the
node-set, it should be considered "document order at the time of
creation of the node-set" which should be good enough to qualify as
spec-compliant (given that the spec does not treat the question of
"reordering" if the tree is modified).

Or no?  One problem with this is that it requires either a tree-walk,
with something keeping track of the positional state and able to
snapshot it each time a node is selected, or an API on the tree that can
return the necessary positional XPath expression equivalent (that would
be easy--getPositionalXPath() { int [] ancestors =
getParent().getPositionalXPath(); int [] result = new int
[ancestors.length + 1]; array copy and append and return result; }. 
Without an API, one might have to walk the entire tree.  Or at least
walk up, and do a discovery walk on the back trail, replacing instances
with integers.

Amelia A. Lewis       amyzing@talsever.com      alicorn@mindspring.com
The Bible contains six admonishments to homosexuals and three hundred 
sixty-two admonishments to heterosexuals.  That doesn't mean that God
doesn't love heterosexuals.  It's just that they need more supervision.

This is a digitally signed message part


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS