[jdom-interest] Namespace issues, et al.

Malachi de AElfweald malachi at tremerechantry.com
Sun Feb 23 18:38:01 PST 2003


On Sun, 23 Feb 2003 20:43:35 -0500 (EST), bob mcwhirter <bob at werken.com> 
wrote:

>> Ok, I misunderstood you guys. I thought you were saying that I had to 
>> change all that
>> to <jbase:request jbase:session=""/>. The point I was trying to make is 
>> that it is perfectly valid
>> (though my personal Schema says not to allow it) for <jbase:request 
>> yourname:session=""/>. What I was
>> trying to say about the spec was that <request session=""/> puts 
>> 'session' into the namespace of the 'request'
>> element (as opposed to the 'yourname' namespace above), thus not needing 
>> to explicitely put jbase:session...
>
> No no no.  That's still a false statement.  The 'session' attribute
> is -NOT-in the namespace of the <request> element, but it is in the
> locality of it.

Ok, so if I do something like:
<objex xmlns="http://www.temporal-wave.com/spec"
		xmlns:xhtml="http://www.w3.org/1999/xhtml"
		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
		xsi:schemaLocation="http://www.temporal-wave.com/spec jbase.xsd
			http://www.w3.org/1999/xhtml http://infomesh.net/2001/xhtmls/xhtml.xsd">
	<request xhtml:href="http://some.url">
		<tagA href="jxta://blah"/>
	</request>
</objex>

The scope of the objex element is the entire thing, with the default 
namespace
being "http://www.temporal-wave.com/spec".  In that scope, the prefix 
"xhtml" is also
defined as "http://www.w3.org/1999/xhtml".

The request ang tagA tags are both defined in jbase.xsd... The first href 
tag is defined in the
xhtml.xsd. The second one is defined in the jbase.xsd.....

Is this correct?



>> As far as your question, you can read it, but not create or validate it.
>>
>> If you try to create that document, you get one of two scenarios...
>> 1) every element says xmlns="http://www.temporal-wave.com/spec" (thus, 
>> lots of overhead over the network)
>
> The outputter/serializer should remove gratuituous ns-decls.  But even it
> doesn't, it's still producing valid/well-formed XML.
>
>> 2) the top element says that, the next one says xmlns="", and then 
>> everything inside that doesn't show xmlns at all.
>
> Though, are your inner elements in the empty namespace?  Or did you
> create them in your namespace?

The issue was 2-fold. If I created them with the xmlns in the constructor, 
I was
also setting the xsi:schemaLocation attribute on it again -- thus the first 
problem.
The second part of it was that I assumed (since textually it is true) that 
putting
a tag inside another (like tagA above) inherits the namespace of the parent 
element.
This is true in XML, and is true in the textual representation -- but JDOM 
changes the
textual representation to break it... Thus, it can not inherit namespaces 
from the parent
because of the fact xmlns="" is being added without my consent. If that one 
piece was not
added, then it would all inherit correctly.

>> Thus, my original request to quit adding xmlns="", as that disables the 
>> current namespace and sets it to null. Thus,
>> every items inside that is invalid.
>
> I have a sneaking suspicioun that JDOM is doing exactly the correct 
> thing.

Well, since the textual representation does not originally have the 
xmlns="", JDOM should not
be adding it. I understand why it is (because JDOM forces you to NOT 
inherit namespaces), but it
should not assume I want xmlns="" unless I specifically tell it to. The 
extra bit of code in JDOM
that does this is what breaks it from behaving like many people have 
thought it should.

>> On the validation side... if I try to validate it as done on the JDOM 
>> FAQ (or on the various suggestions from the list),
>> I get a ClassCastException in Xerces. If I use Xerces directly, it 
>> correctly validates.  Read a few emails ago, there was
>> a link to the bug report I submitted to Apache....
>
> JAXP and Xerces have lots of class-cast exceptions.  Blame sun.
>
> 	-bob


Although, using JAXP + Xerces validates. Using JDOM with it doesn't.

Malachi 



More information about the jdom-interest mailing list