XOM API for Processing XML with Java

["John Cowan" <jcowan AT reutershealth.com>]

Elliotte Rusty Harold scripsit:

> I'd almost rather not make CanonicalXMLSerializer a subclass of 
> Serializer at all. I could just call it Canonicalizer. Since 
> canonicalization doesn't do line wrapping, indenting, encoding 
> detection, or use numeric character references, it actually makes 
> relatively little use of the internals of Serializer.

Based on this, and the fairly small overlap in the API, I think that
this is the most sensible thing to do.

> Big question: is polymorphism necessary here? That is, is it useful 
> to treat an instance of the Serializer subclass as its superclass? 

I don't think so.  Fundamentally, both flavors of Serializer are methods
on Node objects that tell the Node to serialize itself to an output stream.
It's implementationally convenient to encapsulate them, because they
have a fair amount of hidden state that has to be kept somewhere, and as
methods would have an annoyingly large number of arguments.  But I
don't think there's any natural relationship between "serialize" and
"serializeCanonically", any more than between serialization and simple 
"toXML".

Your question about NFC transcoding for Canonicalizer:  Almost all
encodings inherently have the NFC nature, because they have no support
for combining characters.  The exceptions are obscure encodings like
ISO 5426 (aka ISO-IR_53, ANSEL, and GEDCOM) and T.61, which cannot be
transcoded 1-1 to Unicode anyway.

Bug report: The doc comments in NodeFactory still refer to makeElement and
endElement.

-- 
All Gaul is divided into three parts: the part          John Cowan
that cooks with lard and goose fat, the part            www.ccil.org/~cowan
that cooks with olive oil, and the part that            www.reutershealth.com
cooks with butter. -- David Chessler                    
jcowan AT reutershealth.com