[jdom-interest] Namespace patch

[Elliotte Rusty Harold]

At 2:33 PM -0500 8/29/00, Brett McLaughlin wrote:


>Right. Originally, we had things this way - addNamespaceDeclaration()
>and so forth. And though it was a bit different, we came up with the
>notion (which I still agree with) that an Element needs to know its
>namespace declaration, because it's intrinsic to what the Element
>actually is. But that aside, I'm not objectionable to an Element holding
>onto other declarations; the hardest thing becomes what happens to an
>Element being added, presumably one in the "Default" namespace, to an
>Element with a default namespace declaration. Currently, it does what I
>consider the right thing; only an Element with a Namespace has a
>Namespace, and no "magic" happens behind the back of the user; but with
>this proposed change, that isn't so obvious.
>

We could certainly require that every namespace declaration added 
through addNamespaceDeclaration() contain a prefix. I don't see the 
use case where we'd want to use addNamespaceDeclaration() to change 
the default namespace. If somebody tried to do that by passing the 
empty string as a prefix, we could just throw an exception.

Similarly, if somebody tried to add a namespace declaration that 
remapped the prefix on the element or one of its attributes, we'd 
throw an exception.

Trickier question: someone adds an attribute that uses the same 
prefix but a different URI than the one the element itself uses. We 
should probably throw an exception there too.

But what we're really struggling with is the idea that Attribute 
values have namespace prefixes. Therefore maybe we're approaching 
this wrong by focusing on the namespace declarations. Maybe what we 
need is a way to associate a URI with an attribute value. Suppose we 
added an extra field to the Attribute class:

   private Namespace valueNS = null;

We'd add the extra methods necessary to set this and so forth. Since 
attribute values can contain colons for reasons completely unrelated 
to namespaces, we'd only require the namespaceURI be passed to the 
method signatures, not the prefixes which would be passed as part of 
the normal value. For example,

public Attribute(java.lang.String name,
                  java.lang.String prefix,
                  java.lang.String uri,
                  java.lang.String value,  // this includes the prefix
                  java.lang.String valueNS)

public String getValueURI()
public String getValuePrefix()

Existing methods and code that ignored namespaces in attribute values 
would behave the same. Then the XMLOutputter could make sure that 
there was no undeclared prefix in an attribute value.

This seems to me that it would work very well for documents built 
from scratch. However, there might be problems when a document was 
read from a stream since parsers don't report namespace bindings for 
attribute values. Still I think this is surmountable. We'd check each 
attribute value to see if it appeared to contain an in-scope 
namespace prefix mapped to a URI. If so we'd set the URI. Otherwise 
we'd just leave it null.  At worst we'd just have some extra 
namespace mappings floating around that could be ignored by anybody 
who wasn't interested in them. They wouldn't affect anything JDOM 
did, except maybe where the outputters put the xmlns declarations. 
They'd just be there in case client programmers wanted them.

Overall this seems a little more in line with the JDOM design to me. Thoughts?

+-----------------------+------------------------+-------------------+
| 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/     |
+----------------------------------+---------------------------------+