upper-case hex digits [A-F]when marshaling hexBinary elements

Well, given ...

> The canonical representation for hexBinary is defined by prohibiting certain options from the Lexical Representation (§3.2.15.1). Specifically,
> the lower case hexadecimal digits ([a-f]) are not allowed.

it is quite clear that lower case letters are not allowed.

Final patch for review.

Wouldn't it be better to keep support for lower case letters at decoding. This shouldn't harm compatibility to specification but would allow us to be unmarshal documents with lower case letters (backward compatibility).

Actually, yes, removing support for lower case letters would not be a good idea.

Do I understand correctly that the plan is to marshal as uppercase but allow both upper and lower case in validation and unmarshaling of hexBinary types?

Thanks for clarification.

Yes.

I just wonder whether a new property should be introduced to allow backwards-compatibility wrt lower case letters. The question is whether an Exception should be thrown (ideally) if lower case letters are encountered (in the new mode) - to highlight the fact that the XML is invalid (as per spec).

This way one would force users to think before (blindly) accepting wrong input XML.

Improved patch, allowing lower case letters during decoding.

I think you have it correct now and there does not need to be any new property or exception. I interpret the specification to mean that ALL values in the lexical space should be allowed. This means that lower-case is not "invalid". I have verified that other XML validators will accept both lower and uppercase letters in the HexBinary type.

But, by generating in canonical form you provide a consistent output that can be used for strict XML document comparisons, etc. I suppose there could be a property for the validator that specifies "strict" (canonical) form or not. This would effect the validation of alot of different data types.