> It was my understanding that if I could start with an XML file or String, > use one of the xml parsers to load the file into a Document, and then > produce a canonical version of the xml String using an algorithm implement > in the Apache XML Security package. I also assumed that I could load, > using C# .NET, the same original XML file, run the same > canonicalization algorithm as was used in the XML Security package in C# > (specifically the XmlDsigC14NWithCommentsTransform) and produce the same > canonical xml String as the Apache Java package produced.
In the abstract, yes. But if there's a step happening during the parse that causes the DOM to end up slightly different in a significant way, the input to the c14n will not be the same. Whitespace is the most common example because c14n does not do anything special to remove or normalize it beyond the rules that all XML parsers follow, but some parsers (especially validating ones) can collapse or change it in special ways. > I think what you're saying is that this isn't guaranteed to work if my > parsers are by default collapsing whitespace or doing other data > normalization. Usually collapse isn't the default or even that common, but if your input XML has whitespace, and the c14n isn't outputting that whitespace, that's a sign of a problem somewhere, I'd say. Start by leaving out all whitespace (you're going to have to anyway, leaving it in is just asking to have verify problems), and see what happens. Then you can explore why it's causing a problem. > Should this work if all of the DOMs are set to do no data > normalization etc? Normalization commonly happens because of the collapse-ws setting, or because you're schema validating. Validation can usually happen without data normalization, but by default they go together. Apart from that, I don't know. > Also, what are these 
 that appear in both the Glue and C# > canonicalization output? I didn't notice that. I don't know of anything in the process that produces line feed entities. -- Scott
