[jdom-interest] Namespace patch

[Elliotte Rusty Harold]

At 3:00 PM -0400 8/29/00, bob wrote:
>> The big question is whether anyone cares where the namespace prefixes
>> are declared as long as they're declared; i.e. would it matter if a
>> namespace declaration moved from a child node to a parent node?
>
>Yes.  Immensely.  JDOM has no idea how the namespace will be used,
>and by shifting it around, you could be changing the semantics of
>the document.
>

It's not just a question of shifting declarations around randomly. 
The version I submitted is quite careful to make sure that when a 
document is serialized every element and attribute name stays in the 
proper namespace, default or otherwise. Furthermore, every prefix is 
maintained. If it isn't doing that anywhere, that's a bug that needs 
to be fixed. It even handles extremely weird cases like prefixes that 
map to different URIs in different parts of the document.

Given this condition, can you give an example of a case where 
changing where a prefix is declared would change the document in a 
significant way? For example, does XML-SIG consider where the 
namespaces are declared as opposed to merely which namespaces are 
used where in the document?

>Also, remember you can 'unset' namespace prefixes, by using a
>URI of "".  Likewise, I think a prefix can be overriden by inner
>Elements, so foo: might mean one thing to an element, and foo:
>could be completely different to a parent/ancestor.
>

This will all be handled. In fact it's already done in the patch I 
submitted. I agree that this is necessary.


>Yah, it seems that Namespaces are currently keyed by URI alone.
>I think prefix/uri is what we really need to key.
>

That's done in the patch I submitted.

>Regarding the addAttribute()/addNamespaceDeclaration() dichotomy...
>
>getAttributes() does not (and shouldn't!) return namespace declarations.
>So, it seems that addAttribute() shouldn't add namespace declarations
>either.  (If you addAttribute() with 'xml*' namespace, maybe toss an
>exception?)
>
>Hence the added pair of addNamespaceDeclaration() and
>getNamespaceDeclaration() on Element in my patch.
>

The thing is we don't even store these as Attributes. Currently the 
only way to add a namespace to a document is to add an element or 
attribute that uses the namespace in its name or as its default. I 
can see the use-case for fixing that, but I'm just not convinced this 
API is the way to do it.

One thing that accounts for why this is so tricky is that JDOM allows 
Elements to exist that aren't part of a document. Attributes can 
exist that aren't attached to an Element. These elements and 
attributes can have namespace prefixes and URIs, and these need to be 
maintained even in the absence of xmlns declarations.

When we are outputting an entire document, we can algorithmically 
determine where to best place the xmlns attributes necessary to make 
sure that everything is well-formed. However, if we actually store 
the namespace declarations with the elements, then well-formedness 
becomes a question of where an element appears in what tree. Indeed 
the same element could quickly change from an RDF set element to an 
SVG set element to a mathML set element depending on where you put 
it. I don't want to allow that to happen.

+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo at metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
|                  The XML Bible (IDG Books, 1999)                   |
|              http://metalab.unc.edu/xml/books/bible/               |
|   http://www.amazon.com/exec/obidos/ISBN=0764532367/cafeaulaitA/   |
+----------------------------------+---------------------------------+
|  Read Cafe au Lait for Java News:  http://metalab.unc.edu/javafaq/ |
|  Read Cafe con Leche for XML News: http://metalab.unc.edu/xml/     |
+----------------------------------+---------------------------------+