commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lansing, Jeff" <>
Subject RE: [JXPath] Context Namespace-Relative Queries (v1.2)
Date Mon, 18 Apr 2005 15:54:36 GMT
Some points to perhaps consider:
1) Earlier I wrote that:
It seems to me that in practice people distinguish between the "no namespace" namespace, and
a namespace that currently has "" as its prefix.
In this way you get this ("no namespace" namespace):
<?xml version="1.0" encoding="UTF-8"?>
vs. this:
<?xml version="1.0" encoding="UTF-8"?>
<element-a xmlns="urn:something">
which is identical in meaning to this:
<?xml version="1.0" encoding="UTF-8"?>
<foo:element-a xmlns:foo="urn:something">
And something like this makes no sense at all:
  <element-b xmlns="foo">
the convention being that if you're in the "no namespace" namespace, then the whole document
has to be there.
Since then I have noticed that the mixed case does occur in practice (The structure of a SOAP
fault is a good example), and that apparently people think this makes enough sense to be useful.
2) On another note, I have noticed that there are situations where it is difficult or impossible
to add extra namespace declarations to elements containing xpath content, and which would
define the prefixes being used in that content. 
         <wsrp:QueryExpression Dialect="">//ns2:Topics[./@ns2:Dialect='']</wsrp:QueryExpression>
AXIS is a good example of this. It doesn't seem to have any way of adding a declaration of
ns2 to the containing element. (Unless you somehow can get access to the SOAP message itself.)
3) The solution that we adopted in our application was to assume that there was a "well-known"
prefix for the namespace that was being queried against. I think that that most resembles
your case 2, but it is not quite the same.
4) JXPath is a great product, and I think it's worth some effort to make it even better.


From: Dmitri Plotnikov []
Sent: Sun 4/17/2005 8:24 AM
To: Jakarta Commons Users List;
Cc: Lansing, Jeff;
Subject: Re: [JXPath] Context Namespace-Relative Queries (v1.2)


You are not the first to raise this issue.  See for example the discussion
in this bug report:

I think it's time we finally resolve the problem.

We have come up with three alternative solutions so far:

1. Using "null" for namespace prefix.  I don't necessarily like the idea -
it feels atrificial and it blocks access to elements that have no namespace
at all.

2. We introduce this new method on JXPathContext:


Then whenever a name is used without prefix in an XPath, this default
namespace is assumed.  This is effectively the same as 1, except that
aestetically this looks better.  Unfortunately this solution has the same
problem: you can no longer reference elements that really don't have any

3. We introduce this other method on JXPathContext:
   context.setNamespaceIgnored(ns, boolean)

This would allow us to register one or multiple namespaces that should be
ignored altogether.  Let's say
 - you call context.setNamespaceIgnored("abc", true)
 - you have a document that looks like this:

 <foo xmlns:names="abc">

- and you try to resolve the xpath "//a"

This path will return both elements: x and y, one because it does not have a
namespace and the other because its namespace is ignored.

This third option is my favorite.

What do you think?


- Dmitri

----- Original Message -----
From: "Michael Nestler" <>
To: <>
Sent: Thursday, April 07, 2005 1:08 PM
Subject: [JXPath] Context Namespace-Relative Queries (v1.2)

> Hello,
> I recently had to switch from JXPath 1.1 to 1.2 in order to benefit
> from some bug fixes. I am using JDOM 1.0. It appears that JXPath's
> behavior regarding namespaces in JDOM trees changed and became less
> convenient and flexible.
> I have documents like this:
> <html xmlns="">
>  <table>
>    <tr>
>      <td>page</td>
>      <td>type</td>
>      <td>comment</td>
>    </tr>
>    <tr>
>      <td><a href="/Home"/></td>
>      <td>conf</td>
>      <td>Home Page</td>
>    </tr>
>    <tr>
>      <td><a href="/ToolBar"/></td>
>      <td>conf</td>
>      <td>Tool Bar</td>
>    </tr>
>  </table>
> </html>
> The namespace of the root element is variable and might be the XHTML
> namespace, another namespace, or no namespace at all. The table
> structure is always the same, and cell values vary. And I have some
> code that executes the following query:
> SAXBuilder sax = new SAXBuilder();
> Document doc = StringReader(...);
> Element rootElement = doc.getRootElement();
> JXPathContext ctx = JXPathUtil.newContext(rootElement);
> String value = ctx.getValue("/table/tr[2]/td[2]");
> This worked fine with JXPath 1.1, but it doesn't work anymore with
> 1.2. The new JXPath version throws an exception:
> org.apache.commons.jxpath.JXPathException: No value for xpath:
> /table/tr[2]/td[2]
> at
> org.apache.commons.jxpath.ri.JXPathContextReferenceImpl.getValue(
> at
> org.apache.commons.jxpath.ri.JXPathContextReferenceImpl.getValue(
> Why would this not work, considering that all the DOM nodes live in
> the same namespace - the namespace of the context bean (root element)?
> It appears that I can register the XHTML namespace, but then I have to
> use a prefix for every element name in my query - and it won't work if
> the namespace is not set or is different (that's possible in my app).
> Is there a solution to this problem, i.e. is there a way to make
> JXPath interpret the root element's namespace as the default namespace
> requiring no prefix in XPath queries?
> Thanks in advance,
> -Michael
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message