Okay, my apologies for the confusion. I know the canonicalization is not
done by the XML parser. In my tests for both the Glue case, and what I was
calling the javax.xml, I'm simply parsing my test file using the particular
API to create the DOM, and then using the apache java xml security api to
perform the canonicalization.
So, in the glue case, I perform the following:
electric.xml.Document doc = new electric.xml.Document(file);
Canonicalizer c14n =
Canonicalizer.getInstance(Canonicalizer.ALGO_ID_C14N_WITH_COMMENTS);
byte[] bytes = c14n.canonicalizeSubtree(doc.getRoot());
// ... write bytes to file
The output from this code matches in all my tests the output from the C#
canonicalizer (with PreserveWhitespace set to false). This is the output
that includes the 
For the JAXP api, I do the following
DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
factory.setValidating(false);
factory.setNamespaceAware(true);
DocumentBuilder builder = factory.newInstance().
newDocumentBuilder();
Document doc = builder.parse(file);
Canonicalizer c14n =
Canonicalizer.getInstance(Canonicalizer.ALGO_ID_C14N_WITH_COMMENTS);
byte[] bytes = c14n.canonicalizeSubtree(doc);
// ... write bytes to file
The result of this code is a file with the whitespace preserved, no 
entities, and the soap:encodingStyle attribute comes first in the
soap:Envelope element.
For some reason, in my little test case, the canonicalizer renders a
different result with the DOM from the JAXP api then from the Glue api.
Apparently, the result from the JAXP DOM, produces something wrong, as far
as the soap:encodingStyle attribute goes.
What I meant by library (again I wasn't very clear) was in regards to the
libraries I'm using in my test. I just downloaded the latest Xerces 2.6.2,
and put that first in the classpath to see if that might somehow be an
issue. This didn't resolve the issue. There may be something else to this
idea though.
Skip Walker
[EMAIL PROTECTED]
Gossamer Group
Bldg #2, Suite 410
4807 Spicewood Springs Rd.
Austin, TX 78759
(512) 342-2600 Fax (512) 342-2612
-----Original Message-----
From: Scott Cantor [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 31, 2005 11:19 AM
To: security-dev@xml.apache.org; [EMAIL PROTECTED]
Subject: RE: Java XML C14n interop with .Net
> Using my test xml file, both Glue and .NET C# both produce all of these
> 
 elements, while the javax.xml apis produce no 
 entities.
Hmm. Reading the spec, it does say that text nodes get changed such that
"all #xD characters are replaced by 
". So, heh, you're right. Guess I
never noticed, SAML doesn't generally contain linefeeds.
But when you say javax.xml, what do you mean? That API doesn't do c14n, it's
the xmlsec code that does that. Or do you just mean you parsed the document
with JAXP? That should be ok, but I'd have to guess that the difference must
be in that step. A whitespace collapse setting is the only thing that makes
any sense to me.
> The Glue and .NET C# begin
>
> <soap:Envelope
> xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"; ...
>
> But the javax.xml begins differently
>
> <soap:Envelope
> soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/";
Again, this isn't javax.xml, that doesn't have any influence on the c14n
step except for maybe building the input DOM. But, the spec says that
namespace declarations come before other attributes. So the latter would be
wrong.
> So the whitespace issue isn't my only problem. Could this be
> a library issue?
Well, I'm not sure you're canonicalizing here in the Java case. I know they
have interop tests and so forth, so the c14n code isn't *that* broken.
-- Scott
