XOM API for Processing XML with Java

[Elliotte Rusty Harold <elharo AT metalab.unc.edu>]

At 12:25 PM -0500 7/8/03, Bradley S. Huffman wrote:

> Here's my scenerio, I have a attribute with value "one\ntwo" and I set the
> line seperator to "\r\n", after I serialize and re-parse, what's the value
> of that attribute? I think with your proposal it will be "one  two" 
> (2 spaces).
> XOM converts "\n" to "\r\n" on serialization, then the parser normalizes this
> to two spaces since it's in a attribute value and not from a external parsed
> entity (which would have normalized it to a single &#A;, right? Oh 
> what a mess).
> Which means equals() returns false. Plus you have traded one char.  for two.
> To further mess things up the two characters aren't equal to the
> original value of the line seperator. Yuck, yuck, yuck.  Personally, I think
> this will cause more confusion to novice users then just always escaping.


OK, I'm beginning to see half your point. God, what a mess. Days like 
this I hate XML.

I think you've convinced me that setting the line separator is not 
enough to justify not escaping. What I probably should have said 
instead is that if the user turns on indenting or a maximum line 
length, then the serializer is free to muck with white space and line 
breaks in attribute content and text content, etc. However, just 
setting the line separator is not enough to justify removing or 
adding line breaks anywhere.

On the other hand, if the user does set the line separator to a 
linefeed (for example) then I think I'm justified in changing all 
line breaks including those in attribute values to line feeds. The 
resulting line feed would then be escaped in the attribute value so 
that there'd still be a line break there, just possibly not the one 
the user started with.

Finally, if the user doesn't touch the serializer options, it should 
faithfully preserve all white space to the maximum extent possible 
including carriage returns in text nodes. This means escaping those 
too. Bleah. However, since there likely won't be any insignificant 
carriage returns in the document unless the user used a \r escape 
sequence in the Java code, this probably isn't too big a hassle.
--

  Elliotte Rusty Harold
  elharo AT metalab.unc.edu
  Processing XML with Java (Addison-Wesley, 2002)
  http://www.cafeconleche.org/books/xmljava
  http://www.amazon.com/exec/obidos/ISBN%3D0201771861/cafeaulaitA