[jdom-interest] Bug and query

[Rolf Lear]

Hate to be the one to inform you, but JDom is correct, and the produced code
XML exactly represents the XML you asked JDom to create.

Creating an Element without a Namespace argument with "new Element
(tagname)" is exactly equivalent to creating an element as "new Element
(tagname, Namespace.NO_NAMESPACE)". If you want to put an element into a
namespace, you have to tell JDom what namespace to use.

Further, xmlns="" is perfectly valid, and a parser which does not parse it
is not XML Compliant.

Have a look at http://www.w3.org/TR/REC-xml-names/#defaulting and scan down
to where it says "The default namespace can be set to the empty string. This
has the same effect, within the scope of the declaration, of there being no
default namespace."

Rolf

-----Original Message-----
From: Eric VERGNAUD [mailto:eric.vergnaud at wanadoo.fr]
Sent: Wednesday, June 25, 2003 5:29 AM
To: Bradley S. Huffman; Eric VERGNAUD
Cc: jdom-interest at jdom.org
Subject: Re: [jdom-interest] Bug and query 


Thanks Bradley for your feedback,

>>     in XmlOutputter.java, there is come inconsistency in the way
>>     printElement, printElementNamespace, and printNamespace work
together.
>>     This sometimes leads to the following production:
>>     
>>     <tag xmlns:'mynamesapce'>
>>         <childtag xmlns:>
>>         some data
>>         </childtag>
>>     </tag>
>> 
>>     This happens when you set the namespace for an element, but not for
one
>> of its child element.
>>     This can be fixed by changing the code for printElementNamespace by
the
>> following:
>>         Namespace ns = element.getNamespace();
>>         if (ns != Namespace.XML_NAMESPACE && ns !=
Namespace.NO_NAMESPACE)
>>         {
>>             printNamespace(ns, out, namespaces);
>>         }
> 
> Which version of JDOM are you using? In beta 9 and the current cvs, ns
should
> should never be equal to XML_NAMESPACE (which is prefix "xml").  Using the
> prefix "xml" or one that starts with "xml" will throw a exception in
> Namespace.getNamespace. Second "xmlns" is only printed in printNamespace()
> and it always prints a "=" and surrounds the URI with double quotes, so I
> don't see how your example output could happen.

The production is more like the following (sorry for the lack of precision
in my previous post):

     <tag xmlns="mynamespace">
         <childtag xmlns="">
            some data
         </childtag>
     </tag>

I don't know whether xmlns="" is legal, but it's not supported by any parser
I've used. I'm still using b8, but I've checked that this code remains
unchanged in b9. In my case, the problem occurs when ns is
Namespace.NO_NAMESPACE. This is because the current code in
printElementNamespace() calls printNamespace() when either ns is not
Namespace.NO_NAMESPACE OR the namespaces stack is not empty:

        if ( !((ns == Namespace.NO_NAMESPACE) &&
               (namespaces.getURI("") == null))) {
            printNamespace(ns, out, namespaces);
        }

but printNamespace prints an empty namespace when ns is
Namespace.NO_NAMESPACE.

>>  in XmlOutputter.java, the 'output' method ends by the following code:
>>   
>>     // Output final line separator
>>     // We output this no matter what the newline flags say
>>     out.write(currentFormat.lineSeparator);
>> 
>>     out.flush();
>> 
>> Is writing a line separator at the end of the Xml stream mandatory ? I
don't
>> know the answer, but I guess it's no, so I think it should be caller's
>> responsability to add this newline, because while this newline maybe fine
in
>> a xml file, it may not be fine at all in a wireless xml stream, when the
>> other end is expecting a perfectly-formed (not just well-formed)
document.
>> In fact I've met the situation where this newline would cause the other
end
>> parser to fail at some point, and got stuck because I do not have access
to
>> that parser which resides compiled on a mobile device.
> 
> No it's not mandatory, but it should not matter. If it does, then that
> application or the parser it uses it broken.
> 
>> So I would very much prefer:
>>  
>>     // Output final line separator
>>     // We output this no matter what the newline flags say
>>     newline(out);
>> 
>>     out.flush();
>> 
>> What do you think ?
> 
> Have to look, but not printing it when in "raw" mode and printing it
> when in "pretty-printing" mode seems harmless and reasonable.

Thanks, because there is absolutely no way I can fix the bug on the mobile
device's parser. What happens apparently is that because the mobile device
has limited memory, it parses the xml stream on the fly without waiting for
the root closing tag. I guess the -buggy- mechanism which keeps any unparsed
data in the buffer over calls to the receiving socket, leads to a situation
where the 2 line-break characters at the end of the first received document
(which are not parsed), become the 2 leading characters of the second
document (which is not legal).

_______________________________________________
To control your jdom-interest membership:
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhos
t.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://jdom.org/pipermail/jdom-interest/attachments/20030625/a85fb32d/attachment.htm