No subject


Fri Aug 6 17:04:17 PDT 2004


</tagA>
 
In that section of XML, according to section 6.2 of that spec, it states 
that tagA, tagB, and attrC are all in the http://www.eoti.org default 
namespace.
 
Am I misreading the spec? I did notice that XMLOutputter is automatically 
defaulting
to version="1.0" on the XMLDecl.  Perhaps I am trying to use XML 1.1 and 
JDOM is only XML 1.0?
 
If JDOM does in fact support XML1.1, then this is what I see as the 
problems:
1) XMLOutputter should be setting "1.1" not "1.0"
2) attrC should be in the same namespace as tagB, unless it specifies its 
own prefix
3) tagB should be in the same namespace as tagA, unless it specifies its 
own prefix
4) XMLOutputter should NOT add xmlns="" by default, because, according to 
section 6.2 of that spec, that disables the default namespace
5) tagAElement.getChild("tagB") should not require the namespace for the 
method call, because by default it should be in the same namespace
6) tagAElement.addContent(new Element("tagB")) should not require the 
namespace for the method call, because by default it should be in the same 
namespace
 
I want my output to be like the example above (or more correctly like the 
one at http://www.w3schools.com/schema/schema_schema.asp under the title 
"Referencing a Schema in an XML Document").  If I only put the namespace on 
the root element (as per those examples), then the child element has the 
xmlns="" which disables the default namespace. That is bugs #3,4, and 6 
above.  Although the FAQ does say this happens, it does not conform to the 
specification.
 
As a side comment, I don't understand why extra code has been added to JDOM 
to make the namespace handling more difficult for the user. My original 
attempt was to do setAttribute for each of the attributes listed on the 
w3schools example.  I found the answer on how to do it, via old answers on 
the list, but no one has bothered to explain why the code was added 
specifically to make it more difficult. I think adding them with 
setAttribute is much more intuitive, especially for the 
"xsi:schemaLocation" one.
 
I would prefer some constructive comments on this issue, because for all of 
my encouragement for the use of JDOM in the workplace, without meeting the 
specification I will not be able to convince the employeer to use it.  
Currently, they are using Apache's stuff on the C-side, and are more likely 
to enforce I use Apache's API directly instead of JDOM if JDOM can't 
deliver.
 
One other thing. I was trying to do the schema validation with JDOM as per 
the FAQ and various comments on the list. I could never get it to work. 
Specifically, I always got a ClassCastException inside the Xerces, 
regardless of which XML/XSDs I used.  However, using Xerces without JDOM ( 
http://www.acknowledge.co.uk/snippets/java/code_examples/xml/validatingschema.html 
 ) validated my files just fine. I submitted a bug report to Apache,
if anyone is interested. It is located at 
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17267 .
 
Malachi



More information about the jdom-interest mailing list