> What PeiYong mentioned about the Schema production really maybe should be > the job of the Base64 validator, to validate and enforce the production > for 0 or 1.
That's my personal opinion too, but OTOH, Xerces' docs don't say that I should be using the Base64 class myself either, so they don't pretend it's a generic decoder. I did have to code around that because I am using it to decode something that's not in XML, and I had to strip whitespace to do it once 2.2 came out. But buyer beware. I'll probably have to switch decoders at some point. > Just curious why your data which is encoded have multiple line feeds How > did you encode the data? Did you use Xerces C++? The Java xmlsec library inserts some extra linefeeds in some cases when it writes out the Text Node for a certificate in KeyInfo. Specifically if the encoded blob is a byte multiple of the line length, say 76. So the extra linefeed is schema-invalid, as has been noted. My main goal was to confirm that. I've informed them, and they plan a patch, since they certainly agree that their output should be schema valid if possible. In general, I think it's a shame that there isn't one exact way to put base64 into XML. These whitespace issues are a real mess, especially when you sign and verify. It's well known that just validating (which by default does text normalizing) can break signature verification, which is insane. Schema canonicalization should have been in the Signature spec from day one. -- Scott --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
