I don't see the conflict. You're confusing a name test in XPath with the
tag name in an XML document. They are not the same thing. XPath operates
on an instance of the XPath data model, not on markup.
If XPath were to support what you are asking for, it would make for some
serious ambiguities. For example, how would someone find "foo" elements
that are not in a namespace? Since there can be multiple default
namespaces in a document, are you saying you want the XPath to consider the
default namespace that's currently in scope at a particular point in the
tree? That seems bizarre to me. XPath simply puts the burden on the user
to be explicit about what sort of nodes they're looking for.
> It is not a reasonable solution to "Add a namespace
> declaration with a prefix...." as the FAQ suggests,
> since we all must process documents that are produced
> beyond our control.
There is no need to alter the input document, and the FAQ is not suggesting
you do that. Since XPath is meant to be embedded in other specifications,
it relies on those specifications to provide a context for the evaluation
of expressions. One part of that context is a set of namespace
declarations that map prefixes to namespace URIs. In the XSLT environment,
that would be the stylesheet document that contains the XPaths. In a
stand-alone environment like Xalan's XPathAPI, you must implement the
interface org.apache.xml.utils.PrefixResolver. Then, you can use a prefix
in your name tests and bind it to the appropriate namespace URI.
There is some on-going work in XPath 2.0 to allow the user to specify a
default namespace for node tests with unprefixed QNames:
http://www.w3.org/TR/xpath20/#node-tests
"A QName in a name test is expanded into an expanded-QName using the
in-scope namespaces in the expression context. An unprefixed QName used
as a name test has the namespaceURI associated with the default element
namespace in the expression context. It is a static error if the QName
has a prefix that does not correspond to any in-scope namespace."
However, that does not deal with the situation where there are multiple
default namespaces in a document, and you want to find all "foo" nodes in
any namespace. For that, they've added this:
"*:foo"
Which I think is pretty dubious construct, but I guess enough people
thought it was necessary.
Dave
"Jeff Greif"
<[EMAIL PROTECTED] To: "Jeff Greif" <[EMAIL
PROTECTED]>, "Joseph Kesselman"
nceton.edu> <[EMAIL PROTECTED]>
cc: <[EMAIL PROTECTED]>,
(bcc: David N Bertoni/Cambridge/IBM)
11/26/2002 04:14 Subject: Re: xpath constructor
PM
Well, I apologize for being too hasty!
It appears that you guys are caught between conflicting specs, and have
chosen a solution that agrees with one of them. The namespace spec says
that nodes with no prefix belong to the default namespace, but the xpath
spec decides to treat them as though they belong to no namespace. What's a
poor developer to do? The xalan team has chosen to go along with the XPath
recommendation, which clearly makes sense for a product with xpath as a key
component; if there is a better solution it's far from obvious.
But it's unfortunate for those who have to work with documents that use
default namespaces.
Jeff
----- Original Message -----
From: "Jeff Greif" <[EMAIL PROTECTED]>
To: "Joseph Kesselman" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, November 26, 2002 3:58 PM
Subject: Re: xpath constructor
...
> When I parse a document like this using Xerces 2.1.0 DOMParser:
... snipped...
>
> I must use paths like:
> //:verb
> /:interaction/:instructions
> from the XPathAPI in order to access the data.
> If I use paths like
> //verb
> no nodes are found.
>
> Now that I look at the xalan-j faqs, I see that perhaps this is not
supposed
> to work. If that is true, I believe it to be a defect in the xalan xpath
> implementation, which, if conforming to the XSLT spec, should work on any
> legal namespace-aware document (in this case, the real document from
which
I
> excerpted the piece above is validated to the highest extent by Xerces
> against its schema).. It is not a reasonable solution to "Add a
namespace
> declaration with a prefix...." as the FAQ suggests, since we all must
> process documents that are produced beyond our control. Presumably it
will
> not work to transform the documents using xalan-j to add the prefix,
since
> the transformation will depend on xpath and that will fail.. For a
generic
> tool like xalan-j to carve out a subset of legal and valid xml documents
on
> which to work correctly seems a mistake to me.
>
> There is a well-defined mapping at any element node of the above document
> between prefixes (including the null prefix) and namespaces, and there's
no
> good reason why xpath could not be made to use it, either using colons or
> not for the no-prefix namespace.
