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 -----
From: Matt Smith
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.
 

Reply via email to