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.

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 decided to commit this as is .... feel free to add a new follow-up issue if you think that adding a new property does make sense, indeed.

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.