[jdom-interest] Namespace declarations

Brett McLaughlin brett.mclaughlin at lutris.com
Thu Sep 14 09:00:16 PDT 2000

Elliotte Rusty Harold wrote:
> I've been thinking about how to handle namespace declarations that
> don't map to any actual element or attribute in the document. These
> would customarily be prefixes used in attribute values or
> theoretically in element content.  I've only been able to develop two
> solutions to this problem, nether of which I like. Before I start
> writing code, I wanted to toss this out for further discussion.
> Solution 1:
>    Each element keeps track of namespace declarations (i.e. xmlns
> attributes) as well the namespace it actually uses. The builders
> would have to produce these form the input documents (not too hard)

No - and since we need to turn on namespace processing in SAX, this will
be even easier to do.

> and we'd need to add an API for attaching new ones to elements. The

Sure - this is the old addNamespaceDeclaration(Namespace ns) that we
once had (before the Namespace object, though).

> XMLOutputter would need to change as well. We could still (and I'd
> argue should still) not require people to add namespace declarations
> to elements just to declare prefixes actually used on elements and
> attributes. Instead the XMLOutputter could deduce these. It would,

Agreed. Existing code would work as is, because creating an Element in a
Namespace is implicitly adding the declaration. I would also argue that
we don't store the Element's own Namespace in the declarations Map (or
whatever); that would just contain additional ones.

> however, check to make sure that it wasn't duplicating an existing
> xmlns declaration.

This is where it gets hairy...

> Thorniest issue with this approach: How do we handle conflicts
> between xmlns attributes and the prefixes actually used? More error
> checking and exception throwing is needed to prevent the possibility
> of using the same prefix or default namespace to refer to more than
> one URI within a single start tag. In fact we actually need this now,
> because it's possible for attributes and elements to define the same
> prefix in multiple ways within a start tag.

I think this is not so ugly a solution - the API is kept really clean
(one, maybe two [if you add a removeXXX()] new methods) is not bad. It
does make implementation a little tricky, but I think that's OK. The
hardest part, though, is the validation, as you point out. But then
again, it's also true that we need this anyway. So let's delve into that

> Solution 2:
>    We allow attribute values to have a namespace URI attached to them.
> This would be optional. Most people wouldn't need to use this. The
> builders would still need to change to look for things that appeared
> to be prefixes in attribute values.  There's still a possibility of
> conflict between different prefixed names with the same prefix in a
> single start tag. Also I'm not sure it's at all intuitive.  Question:
> would there ever be more than one namespace prefix in a single
> attribute value?

This still doesn't solve, as far as I can see, the problem of an Element
having multiple namespace declarations on it, like the stylesheet
element in an XSL stylesheet. So I'm not sure it solves one of the
problems we have.


> I'd still like to come up with a solution that's cleaner than either
> of these. If anyone has any ideas I'd love to hear them.
> --
> +-----------------------+------------------------+-------------------+
> | 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/     |
> +----------------------------------+---------------------------------+
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com

Brett McLaughlin, Enhydra Strategist
Lutris Technologies, Inc. 
1200 Pacific Avenue, Suite 300 
Santa Cruz, CA 95060 USA 

More information about the jdom-interest mailing list