Scott,

    In order to be consistent with XercesJ, and actually that is what XercesJ does now, is to
expose the normalized/unnormalized value in DOM based on the DOM L3's normalization_data
flag, while always get internal representation normalized and in your case, the base64 data
containing line feed, and multiple whitespaces be validated and accepted should the normalized
base64 is valid.

Rgds,
PeiYong




"Scott Cantor" <[EMAIL PROTECTED]>

10/22/2004 12:14 PM

Please respond to
xerces-c-dev

To
<[EMAIL PROTECTED]>
cc
Subject
RE: Base64 validator even more strict?





> The current behavior needs to change so that the flag has an effect on
> DOM content only (more precisely, element content only. Attribute
> normalization is always done).

Sorry if I'm being obtuse, but this is fairly critical for my library, so
I'm trying to be clear...

As far as I know, the current behavior regarding normalization is fully
correct. It normalizes when true and not when false. The fact that
normalizing breaks signatures is just a nasty side effect of the schema spec
and the canonicalization specs not mixing well. It's bad, but it can't
really be helped, unless the normalized values are exposed through a
different API from the DOM, since the xml-security code will use the DOM.

But, the problem in 2.6.0 is that the base64 datatype validator *cannot*
accept unnormalized values anymore. It did before. IMHO, this isn't
technically a bug. But it does make 2.6.0 unusable in my application and I
have to distribute my own source for Xerces to get around this (I also
needed a fix for the unfixed xml:lang bug, so I patched that too).

Xerces-J is different. They are not following the letter of the spec, I
suppose. But it also functions. Sometimes that's the overriding concern as a
programmer.

So I guess I'm pleading for Xerces-C to be consistent with Xerces-J, but if
not, I'll have to work around the problem for now and later just stop
validating. Or parse twice, but that won't be desirable.

-- Scott


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Reply via email to