Re: Resolution of XPath DOM LC issue B5

>One problem that limits the usefulness is the lack of a similar accessor
>in the Traversal module

Granted, unless we want to add getOwnerElement there as well.

BUT: I'm not convinced that this is a killer. We aren't claiming that the 
Traverser presents the XPath view, right? Note that you said
        >especially where a EntityReferences may be present
which is something the traverser could support trivially by setting 
whatToShow to exclude EntRef nodes. If we haven't already made that effort 
(not to mention filtering text-node-not-first-in-sequence), then 
Traverser.getOwnerElement by itself isn't a make-or-break issue.

Note that folks could still use the traverser to find the matching nodes, 
then switch to normal DOM operations -- including the generalized 
ownerElement attribute -- to navigate from those nodes. And in fact that's 
what I'd generally expect them to do, since they'd generally want to leave 
this traverser primed to look for the next node found by the XPath.



Pure brainstorming: It is almost possible to create a Traverser which 
encapsulates the XPath view of the document, by setting appropriate 
filters... and I think it actually would be possible if Traverser added a 
getOwnerElement method. The filtering to handle text wouldn't be very 
efficient ... but it Could Be Done.

(And it might be more efficient in an implementation designed to use 
internal information to optimize this case. We always did have the idea 
that some traversers, particularly those returned from queries, might be 
specially coded for better performance....)


______________________________________
Joe Kesselman  / IBM Research

Received on Friday, 6 September 2002 13:08:02 UTC