> It's the identity transform - that should not do anything except store the > DOMSource in a Result.
Not if you're pretty printing with some kind of indent flag. That can't possibly do what it says if it's really an identity transform.... > Isn't the whole idea of XML Signature and Canonicalisation that exactly this > should not happen? Yes, but they don't work well, and it very much depends on namespace handling and the specifics of your document whether you'll break something by running it through a c14n step yourself. That can affect the namespaces in a destructive manner depending on the c14n the signature or reference(s) are using. Many serializers also affect namespaces in odd ways. > When I hand XML over to some HTTP agent, there are almost > certainly small changes (linefeeds etc.) that happen on the way to the > destination. If you change the whitespace, you're dead. None of the standard c14n algorithms will handle that. Whitespace is significant in XML, so it *will* change the digest. This is often surprising to people, but it's true. If you have some way to recover the original XML by knowing what whitespace was added or removed, then sure, you could deal with it, but in effect that's like having a new c14n or transform algorithm. > In essence, what I need is to transfer the XML between sender and receiver. > What kind of serialisation would you recommend for the transfer? I definitely wouldn't use code that was likely to affect the DOM in any way. I would simply write out the DOM node by node using a serializer that was designed to do nothing else to it. Namespaces are another matter...it's often necessary to have a layer of code that handles namespace declarations up front so that the serializer isn't responsible for guaranteeing well-formedness. And that doesn't even cover extension namespace issues, xsi:types, and so forth, where c14n itself has problems. My project has an entire library layer around DOM and xmlsec to address that stuff. But you have to be *very* certain about no whitespace changes, above all else. That's the one thing we know will break it. That can have implications for your parser, of course, since you don't want it collapsing whitespace, and schema normalization will also affect linefeeds (not that you're validating, but it's an example). -- Scott
