[jdom-interest] getChild and namespace

elephantwalker elephantwalker at home.com
Tue Mar 27 22:05:37 PST 2001

real life is calling, but I had to get back to this on.

You are right about the symbol instead of defs. That was just a typo, I
meant to type defs, but typed symbol (I know defs is four letters and symbol
is 6 letters, but when my fingers are flying over the key board, I sometimes
get confused...its a constance source of bugs in my code ;)).

I pulled this example from a much more complex case, and in that case, the
xlink namespace was declared. I just forgot to put it in the simple example,

With crimson, my working parser now, I do not have any problems parsing svg
files generated by adobe illustrator, or our own svg editor. We make use of
lots of symbols, xlinks and use elements, along with several homegrown
namespaces for non graphical data. This is how we caught up to this problem.

We have client side javascript code which uses dom 2 to manipulate the svg
files, and we have similar jdom code on the serverside to manipulate the
code. I find the jdom code to be much more consise and easy to use, since we
use collections in our code everywhere, and are vary used to manipulating

Not being able to access the children without explicitly declaring the
default namespace is a bit of a pain. Certainly it won't break our back to
type a few more bits (we have already done this), and we can declare our own
static code to do it anyway. My point before was, if we have to declare it
as a static function, and use it all the time, then anybody using multiple
namespaces will have to do that. Thats when you have to consider moving
something from "nice to have feature" to "oops, we forgot about this,
because nobody was using multiple namespaces when we did it".

In addition, if you wrote jdom java code this year to work with an invoice
for a hospital, and next year they decided to break charges out for the
emergency room from the rest of the invoice with a new namespace, all of the
code you wrote this year would be broken. What you would like to do is
inherit your old invoice class, and add the various bits for the emergency
room namespace in the inherited emergency room invoice class, but you can't
do that, because the super class is *fubar* when you declared a  new
namespace in your xml file.

Another way to get around this is just to depricate the getChild(name)
method, and force people to use a namespace...but then there would be open
revolt. Lets not do that.

There should be some discussion of this, I can't believe we are the only
people faced with this issue.



-----Original Message-----
From: jdom-interest-admin at jdom.org
[mailto:jdom-interest-admin at jdom.org]On Behalf Of
philip.nelson at omniresources.com
Sent: Tuesday, March 27, 2001 9:10 PM
To: jdom-interest at jdom.org
Subject: RE: [jdom-interest] getChild and namespace

OK I can parse *some* of the adobe examples.

> If you have a default namespace (usually the name of the dtd
> without the
> .dtd extension), and there are other namespaces declared in
> the root element
> of your document....
> <?xml version="1.0" encoding="iso-8859-1"?>
> <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 20000303 Stylable//EN"
> "http://www.w3.org/TR/2000/03/WD-SVG-20000303/DTD/svg-20000303
> -stylable.dtd"
> >
> <svg  xmlns:a="http://www.adobe.com/svg10-extensions"
> a:timeline="independent">
>   <defs>
>     <symbol id="rectangle" >
>     <path  d="M0,0L0,50L50,50L0,0z" />
>     </symbol>
>   </defs>
>   <g>
>     <use xlink:href="#rectangle" />
>   </g>
> </svg>
> If you do a doc.getRootElement(), and then get the Namespace
> it is the path
> to the dtd without the dtd extension.

[Namespace: prefix "" is mapped to URI "
http://www.w3.org/2000/svg-20000303-stylable "]

The spaces are a strange carryover from the fact that the namespace is
declared in the dtd as an entity.  It caused problems with some of the other
Adobe examples but not here.  The space should have blown up but the check
is not in Verifier yet and if it was in there, none of the Adobe examples
will work without doing a trim before setting the uri.

By the way, the xlink:href was not declared anywhere in this example and I
had to cut it out.

> If you do a
> root.getChild("defs"), the
> return is null, but if you do

defs is null: true

> root.getChild("defs",root.getNamespace()), you
> get the symbol element.

nope. The defs element is returned (whew!)

defs namespace: [Namespace: prefix "" is mapped to URI "
http://www.w3.org/2000/svg-20000303-stylable "]
defs name: defs

Here is the code I used;

XMLOutputter out = new XMLOutputter("  ", true);

SAXBuilder builder = new SAXBuilder();
Document doc = builder.build("file:///e:/temp/test.xml");
out.output(doc, System.out);

Element root = doc.getRootElement();

Element defs = root.getChild("defs");

System.out.println("defs is null: " + (defs == null));
defs = root.getChild("defs", root.getNamespace());
System.out.println("defs namespace: " + defs.getNamespace());
System.out.println("defs name: " + defs.getName());

> I am sorry, but how can that be a practical implementation?
> Its not very
> polymorthic. That is, jdom code written for xml with no
> namespace's should
> work the same as code written for the default namespace. It makes the
> getChild("name") method almost useless, because any minor
> change in the xml
> document over time will almost certainly include new
> namespaces, but the
> presense of a default namespace will not change.

I guess I can see your point.  It would be a change that could break a lot
of code. It was heavily discussed in September 2000 so if you want to take
up the fight, you should read those posts by Elliote Rusty Harold and Peter
Gadjokov, subject "Accessing Child Elements".  However, I don't see how, if
you have used getChild(name, parent.getNamespace()) you would be at any more
risk later if your childrens namespaces changed.  They would still not match
the parents default namespace, if it existed.  What you suggest is a
convienience but not a huge one.
To control your jdom-interest membership:

More information about the jdom-interest mailing list