<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2655.35">
<TITLE>RE: [jdom-interest] Bug and query </TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=2>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.</FONT></P>
<P><FONT SIZE=2>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.</FONT></P>
<P><FONT SIZE=2>Further, xmlns="" is perfectly valid, and a parser which does not parse it is not XML Compliant.</FONT>
</P>
<P><FONT SIZE=2>Have a look at <A HREF="http://www.w3.org/TR/REC-xml-names/#defaulting" TARGET="_blank">http://www.w3.org/TR/REC-xml-names/#defaulting</A> 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."</FONT></P>
<P><FONT SIZE=2>Rolf</FONT>
</P>
<P><FONT SIZE=2>-----Original Message-----</FONT>
<BR><FONT SIZE=2>From: Eric VERGNAUD [<A HREF="mailto:eric.vergnaud@wanadoo.fr">mailto:eric.vergnaud@wanadoo.fr</A>]</FONT>
<BR><FONT SIZE=2>Sent: Wednesday, June 25, 2003 5:29 AM</FONT>
<BR><FONT SIZE=2>To: Bradley S. Huffman; Eric VERGNAUD</FONT>
<BR><FONT SIZE=2>Cc: jdom-interest@jdom.org</FONT>
<BR><FONT SIZE=2>Subject: Re: [jdom-interest] Bug and query </FONT>
</P>
<BR>
<P><FONT SIZE=2>Thanks Bradley for your feedback,</FONT>
</P>
<P><FONT SIZE=2>>> in XmlOutputter.java, there is come inconsistency in the way</FONT>
<BR><FONT SIZE=2>>> printElement, printElementNamespace, and printNamespace work together.</FONT>
<BR><FONT SIZE=2>>> This sometimes leads to the following production:</FONT>
<BR><FONT SIZE=2>>> </FONT>
<BR><FONT SIZE=2>>> <tag xmlns:'mynamesapce'></FONT>
<BR><FONT SIZE=2>>> <childtag xmlns:></FONT>
<BR><FONT SIZE=2>>> some data</FONT>
<BR><FONT SIZE=2>>> </childtag></FONT>
<BR><FONT SIZE=2>>> </tag></FONT>
<BR><FONT SIZE=2>>> </FONT>
<BR><FONT SIZE=2>>> This happens when you set the namespace for an element, but not for one</FONT>
<BR><FONT SIZE=2>>> of its child element.</FONT>
<BR><FONT SIZE=2>>> This can be fixed by changing the code for printElementNamespace by the</FONT>
<BR><FONT SIZE=2>>> following:</FONT>
<BR><FONT SIZE=2>>> Namespace ns = element.getNamespace();</FONT>
<BR><FONT SIZE=2>>> if (ns != Namespace.XML_NAMESPACE && ns != Namespace.NO_NAMESPACE)</FONT>
<BR><FONT SIZE=2>>> {</FONT>
<BR><FONT SIZE=2>>> printNamespace(ns, out, namespaces);</FONT>
<BR><FONT SIZE=2>>> }</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> Which version of JDOM are you using? In beta 9 and the current cvs, ns should</FONT>
<BR><FONT SIZE=2>> should never be equal to XML_NAMESPACE (which is prefix "xml"). Using the</FONT>
<BR><FONT SIZE=2>> prefix "xml" or one that starts with "xml" will throw a exception in</FONT>
<BR><FONT SIZE=2>> Namespace.getNamespace. Second "xmlns" is only printed in printNamespace()</FONT>
<BR><FONT SIZE=2>> and it always prints a "=" and surrounds the URI with double quotes, so I</FONT>
<BR><FONT SIZE=2>> don't see how your example output could happen.</FONT>
</P>
<P><FONT SIZE=2>The production is more like the following (sorry for the lack of precision</FONT>
<BR><FONT SIZE=2>in my previous post):</FONT>
</P>
<P><FONT SIZE=2> <tag xmlns="mynamespace"></FONT>
<BR><FONT SIZE=2> <childtag xmlns=""></FONT>
<BR><FONT SIZE=2> some data</FONT>
<BR><FONT SIZE=2> </childtag></FONT>
<BR><FONT SIZE=2> </tag></FONT>
</P>
<P><FONT SIZE=2>I don't know whether xmlns="" is legal, but it's not supported by any parser</FONT>
<BR><FONT SIZE=2>I've used. I'm still using b8, but I've checked that this code remains</FONT>
<BR><FONT SIZE=2>unchanged in b9. In my case, the problem occurs when ns is</FONT>
<BR><FONT SIZE=2>Namespace.NO_NAMESPACE. This is because the current code in</FONT>
<BR><FONT SIZE=2>printElementNamespace() calls printNamespace() when either ns is not</FONT>
<BR><FONT SIZE=2>Namespace.NO_NAMESPACE OR the namespaces stack is not empty:</FONT>
</P>
<P><FONT SIZE=2> if ( !((ns == Namespace.NO_NAMESPACE) &&</FONT>
<BR><FONT SIZE=2> (namespaces.getURI("") == null))) {</FONT>
<BR><FONT SIZE=2> printNamespace(ns, out, namespaces);</FONT>
<BR><FONT SIZE=2> }</FONT>
</P>
<P><FONT SIZE=2>but printNamespace prints an empty namespace when ns is</FONT>
<BR><FONT SIZE=2>Namespace.NO_NAMESPACE.</FONT>
</P>
<P><FONT SIZE=2>>> in XmlOutputter.java, the 'output' method ends by the following code:</FONT>
<BR><FONT SIZE=2>>> </FONT>
<BR><FONT SIZE=2>>> // Output final line separator</FONT>
<BR><FONT SIZE=2>>> // We output this no matter what the newline flags say</FONT>
<BR><FONT SIZE=2>>> out.write(currentFormat.lineSeparator);</FONT>
<BR><FONT SIZE=2>>> </FONT>
<BR><FONT SIZE=2>>> out.flush();</FONT>
<BR><FONT SIZE=2>>> </FONT>
<BR><FONT SIZE=2>>> Is writing a line separator at the end of the Xml stream mandatory ? I don't</FONT>
<BR><FONT SIZE=2>>> know the answer, but I guess it's no, so I think it should be caller's</FONT>
<BR><FONT SIZE=2>>> responsability to add this newline, because while this newline maybe fine in</FONT>
<BR><FONT SIZE=2>>> a xml file, it may not be fine at all in a wireless xml stream, when the</FONT>
<BR><FONT SIZE=2>>> other end is expecting a perfectly-formed (not just well-formed) document.</FONT>
<BR><FONT SIZE=2>>> In fact I've met the situation where this newline would cause the other end</FONT>
<BR><FONT SIZE=2>>> parser to fail at some point, and got stuck because I do not have access to</FONT>
<BR><FONT SIZE=2>>> that parser which resides compiled on a mobile device.</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> No it's not mandatory, but it should not matter. If it does, then that</FONT>
<BR><FONT SIZE=2>> application or the parser it uses it broken.</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>>> So I would very much prefer:</FONT>
<BR><FONT SIZE=2>>> </FONT>
<BR><FONT SIZE=2>>> // Output final line separator</FONT>
<BR><FONT SIZE=2>>> // We output this no matter what the newline flags say</FONT>
<BR><FONT SIZE=2>>> newline(out);</FONT>
<BR><FONT SIZE=2>>> </FONT>
<BR><FONT SIZE=2>>> out.flush();</FONT>
<BR><FONT SIZE=2>>> </FONT>
<BR><FONT SIZE=2>>> What do you think ?</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> Have to look, but not printing it when in "raw" mode and printing it</FONT>
<BR><FONT SIZE=2>> when in "pretty-printing" mode seems harmless and reasonable.</FONT>
</P>
<P><FONT SIZE=2>Thanks, because there is absolutely no way I can fix the bug on the mobile</FONT>
<BR><FONT SIZE=2>device's parser. What happens apparently is that because the mobile device</FONT>
<BR><FONT SIZE=2>has limited memory, it parses the xml stream on the fly without waiting for</FONT>
<BR><FONT SIZE=2>the root closing tag. I guess the -buggy- mechanism which keeps any unparsed</FONT>
<BR><FONT SIZE=2>data in the buffer over calls to the receiving socket, leads to a situation</FONT>
<BR><FONT SIZE=2>where the 2 line-break characters at the end of the first received document</FONT>
<BR><FONT SIZE=2>(which are not parsed), become the 2 leading characters of the second</FONT>
<BR><FONT SIZE=2>document (which is not legal).</FONT>
</P>
<P><FONT SIZE=2>_______________________________________________</FONT>
<BR><FONT SIZE=2>To control your jdom-interest membership:</FONT>
<BR><FONT SIZE=2><A HREF="http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com" TARGET="_blank">http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com</A></FONT>
</P>
</BODY>
</HTML>