Dims, all,
just looked at CanonicalizerBase and did a quick test. Unfortunatly it also handles CDATA in a wrong way - it handles CDATA like standard Text nodes, i.e. C14nBase converts all special chars into Entities and serialize CDATA as standard text without the "[!CDATA[....]]" sequence. I don't know if this is by purpose or a bug.
The spec requires this. Implementations must first convert CDATA sections into their character content and then in a later step resolve all entity references.
MInd you, it's also the recommended approach within the encryption standard. The C++ implementation uses EXC-C14n. (Although it really should be a slightly modified form to handle the nasty case where the default namespace gets stripped because it isn't needed by canonicalisation.)
IMO, for encryption serialization CDATA shall be serialized as CDATA element without Entity conversion. Otherwise it may give problems when we first sign that element, then encrypt it. In addition CDATA implies a "preserve space" behavior. Is that true for standard Text nodes too?
As I understand it - yes.
2.10 of the XML 1.0 spec -
"An XML processor must always pass all characters in a document that are not markup through to the application"
The xml:space attribute can be used to signal whether white space should be preserved, but this is, AIUI, simply a guide for the application - the parser should not act on it.
The XMLSerializer of Xerces also deals with DOM 3 enhancements, does quite some processing with namespace and so on (I didn't understood it in every detail). I can't find this namespace handling at C14nBase. At all it is a quite heavyweight method/Class. Maybe we can extract it and move it over.
The namespace handling is done by the implementation classes, as the behaviour changes fairly drastically according to whether it is inclusive or exclusive XML.
Namespace handling can get nasty in encryption, so maybe using EXC-C14n in the java code might be a good idea.
Cheers,
Berin