You could write your own XPathFactory and create
your own NamespaceContext implementation to do this if you wish.
Or just create a single NamespaceContext with all
the namespace URIs you want to use in your XPath expressions.
This latter option is more flexible and can work
with any input documents. The former is more brittle and can break if you're not
in control of the input XML documents.
James
----- Original Message -----
Sent: Tuesday, April 30, 2002 7:32
AM
Subject: Re: [Jaxen] problem with
namespaces?
Thanks for the explanation. I figured that was the case for
the null-namespace, but you're right that I was thinking of the issue
backwards; the prefix is arbitrary, not the namespace.
In light of
this, however, I think that James Strachan's XPathFactory is an appealing
idea.
I was wondering how XPathAPI managed to handle this without me
doing any work, and I poked around the source and discovered that it makes
goes and figures out namespaces mappings from the passed in
element.
-Matt
----- Original Message ----- From: "bob
mcwhirter" <[EMAIL PROTECTED]> To:
"Matt Smith" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent:
Monday, April 29, 2002 10:51 PM Subject: Re: [Jaxen] problem with
namespaces?
An xpath step is in the form of 'prefix:local-name', but
when performing matching, we actually match against the URI, *not* the
prefix. This is actually a feature of the XPath spec. It allows
you to write XPaths without caring how someone binds the prefix/URIs in the
document. While you might always use "xs:", someone else might use
"cheese:", but as long as they all point to the same ns-URI, then your
XPath will work on both of them.
So, short answer: No, node is *not*
identified by untranslated name. It's identified by namespace-URI and
local name. Prefix is only used to lookup the URI, not for actual
matching.
|