XOM API for Processing XML with Java

["Bradley S. Huffman" <hip AT cs.okstate.edu>]

Elliotte Rusty Harold writes:

> The basic idea is that if the user has told the serializer to change 
> the white space, then it will. However, if the user has not told the 
> serializer to change the white space, then it won't.

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.

If you always escape then "one\ntwo" -> serialize -> "one&#D;two" ->
parse -> "one\ntwo", simple, easy to remember :-)

Plus more seasoned users can always use a SAX filter or some other type of
filtering to do any normalization/conversion required by their application
so no one is being limited.

Simialer arguments for converting characters in text nodes to the current
setting of line seperator.  It's just to ugly.

> Possibly what all this needs is a couple more options on the 
> serializer to more explicitly control how data is serialized. Yuck. 
> This a really messy part of XML. I think anything we do here is 
> likely to be ugly.

Or less, what if you deprecated setLineSeperator and always use &#A;.
If you want "\r\n" for a line break wouldn't a simple wrapper around the
output stream be the way to go?

Brad