[XOM-interest] Swap Node.toString() and Node.toXML()

Elliotte Rusty Harold elharo at metalab.unc.edu
Fri Dec 5 19:28:58 EST 2003


>Hi,
>
>Please consider swapping the meaning of Node.toString() and 
>Node.toXML() and renaming the new toXML() --> toShortString() or 
>toDebugXML() or similar.

>IMHO, and the principle of least surprise, the standard string 
>representation of an XML Object, i.e. toString() should not yield a 
>debug info, but the full XML. Whoever needs abbreviated debug info 
>should explicitly call toShortString().

I disagree. The purpose of toString() is debugging, and in general 
toString() methods do not and should not have guaranteed behavior 
beyond that. Yes, there are exceptions to this in the JDK, but there 
are a lot of exceptions to many rules of good Java design in the JDK, 
and like most these came about because in the early days not all the 
JavaSoft programmers fully understood the rules of good Java design.

According to the JavaDoc for toString(), "In general, the toString 
method returns a string that "textually represents" this object. The 
result should be a concise but informative representation that is 
easy for a person to read." Notice in particular the suggestion that 
it be "concise". An XML element may be very unconcise.

>In my experience, even for logging, most of the time one needs the 
>full XML (new toString()), rather than some abbreviated data with 
>max. 40 chars per Text object.

For logging it's important not to have toString() return data which 
may contain line breaks. This can royally muck up various log formats.


>I think this would be easier and more intuitive, for example when 
>passing xom objects to third parties.

When passing objects to third parties it is even more essential that 
toString() indicate the class of the object being passed. This is not 
done by toXML.

>Also, one might even have toString() delegate to a serializer 
>configured for indented pretty printing, since this is what one 
>wants most of the time anyway. (This would, of course, not preclude 
>other explicit serializations such as canonical, etc.)

XOM's basic rule is it won't give you a different infoset than what 
you asked for. It will not pretty print unless told to explicitly.


-- 

   Elliotte Rusty Harold
   elharo at metalab.unc.edu
   Effective XML (Addison-Wesley, 2003)
   http://www.cafeconleche.org/books/effectivexml            
   http://www.amazon.com/exec/obidos/ISBN%3D0321150406/ref%3Dnosim/cafeaulaitA 



More information about the XOM-interest mailing list