Re: Namespace resolver in DOM-XPath (suggests additional Node method in Core)

The downsides of passing in a string:

1) You have to generate the string, then reparse it. Wasted work if the
data was already in an easier-to-retrieve form.

2) You have to build a complete list; you can't defer resolution and
compute it on demand. This too may impose additional costs. In use case B,
for example, you may have to walk the context-node's parents to gather
namespaces; a string requies you scan them all, whereas an API has the
option of looking back only as far as necessary for this query, and looking
farther at a later time if another query has not yet been resolved.

Abstracting this into a NamespaceResolver API leaves us room to consider
those issues.

 If someone wants to use a single string internally, that's fine. And
perhaps we should consider a factory that accepts such a string and returns
a NamespaceResolver with that content.  But I think nailing it down as only
a string would excessively constrain implementations.

______________________________________
Joe Kesselman  / IBM Research

Received on Monday, 16 July 2001 11:57:05 UTC