[jdom-interest] recursive getAdd'lNS()?

bob bob at accurev.com
Fri Oct 13 20:53:08 PDT 2000

> At the risk of revealing my lack of sleep, I'm not sure I get what you 
> are wanting. Can you try and re-explain? I'm totally lost :(

I probably wasn't that clear to begin with. ;)

Many applications (XSLT for one) care not simply about which namespaces
were declared on a particular Element, but rather, the entire set
of namespace declarations between the root of the document, and a
particular Element.

If you have three nested Elements <a>, <b>, and <c>, XSLT likes
to know the cummulative list of prefix->URI mappings from <a>
to <c>.  

Basically, the namespace prefix->URI map consists of of the
mappings of the entire lineage from the root element to the
current element you're inspecting.

<a xmlns:foo="http://www.foo.org/">
  <b xmlns:bar="http://www.bar.org/">

For the <c> element, even though getAdditionNamespaces()
would return the EMPTY_LIST, in this case, the applicable
namespace mappings include foo: and bar: prefixes.

Additionally, though, I *think* the spec says that an
Element may override the prefix-mapping of any ancestor.

So, <c> could redefine the foo: prefix->URI mapping
to a completely URI.  

What I'd like, personally, is something like:

	List getCurrentlyApplicableNamespaces();

which would in essense, walk the tree from root to this
Element, collecting prefix->URI mappings, allowing children
to override ancestors, producing the list of applicable
Namespaces.  I'd then use that list to resolve the
values of my attributes, which might be like

	<c my_xpath="foo:elementA/bar:elementB"/>

There, I'd know that 'foo:' is http://www.foo.org/, while
'bar:' is http://www.bar.org/.

Sure, I could implement this outside of the jdom Element
class, but it seems to be something that could be useful
to other applications which expect NSprefixes inside of
attribute values.

Make more sense?  


More information about the jdom-interest mailing list