[
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.
Amy!
--
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
|
