Re: SAX Filters for Namespace Processing

[Daniel Veillard <veillard@redhat.com>]

On Sun, Aug 05, 2001 at 05:00:49PM -0400, Jonathan Borden wrote:
> > The reason it wasn't there is because in order to support namespaces,
> > most XPath implementations require a context node for prefix
> > resolution.  The context node is usually an element in the document that
> > is being queried, and it's usually an element that has been sufficiently
> > drilled down to so that the prefix you use in the XPath actually matches
> > the namespace you're looking for.

  Actually in libxml I provided 2 mechanism to pass namespaces mappings
to the XPath engine:
   - one static, useful for example for XPointer where the prefixes
     are not inherited from the XPath location context (XPointer won't
     inherit the namespaces mapping of the element carrying it if embedded
     in an XML document).
   - one dynamic, each time that you call the XPath API you add the
     namespace list in scope to the XPath context. that list can be
     build from the context node.
  
> Right, this is a real issue.
> 
> A reasonable solution is what XPointer has come up with namely:
> 
> "xmlns(prefix=http://example.com/namespace) xpointer(//prefix:example)"
> 
> not that it is pretty, but does the job.

  Well it was added at the last moment, and this was looking like the
simplest way to add this to the existing framework, we were seriously
constrained.

> i'd prefer if xpointer had provided
> for an xpath(//this:is/an:xpath) syntax, but that's another story.

  Yes, this would not solve the namespace mapping ;-)

> Another solution would be for the API to accept a namespace context map ...

  Exactly, you may actually need both for different use cases.

Daniel

-- 
Daniel Veillard      | Red Hat Network http://redhat.com/products/network/
veillard@redhat.com  | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/