Re: spec. problem: hexBinary, base64Binary value sets disjoint and not disjoint

Dave Peterson wrote:
> At 5:30 PM -0400 2009-09-01, Barclay, Daniel wrote:
>> In the XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes CR
>> at http://www.w3.org/TR/2009/CR-xmlschema11-2-20090430, section 2.2.3
>> says:
>>
>>    For purposes of this specification, the value spaces of primitive
>>    datatypes are disjoint, even in cases where the abstractions they
>>    represent might be thought of as having values in common.
>>
>> However, the specification goes on to define the value spaces of
>> hexBinary and base64Binary to be the same set of values:
>>
>> Section 3.3.16.1, Value Space (for hexBinary) says:
...
>> Section 3.3.17.1, Value Space (for base64Binary) says, identically:
...
>> Since:
>> - the value space of hexBinary is the set of finite-length
>>    sequences of zero or more binary octets, and
>> - the value space of base64Binary is _also_ the set of finite-length
>>    sequences of zero or more binary octets,
>> then those two value spaces are the same set.  Since the are the
>> same set, they clearly are not disjoint.
> 
> The whole point of the firrst paragraph you quoted is to say that
> in the situations like the one you mention (similarly, e.g., for
> decimal, double, and float) the members of the value space are
> artificially distinguished in the various primitive datatypes
> involved.  True for any primitive datatypes whose value spaces as
> described appear to have values in common.

Right, but the first paragraph only says that value spaces are
disjoint for things that "might be thought of as having values in
common."

Its wording is not strong enough to say that they are disjoint even
when other specification wording directly implies that they are not
disjoint.


Either the hexBinary and base64Binary paragraphs need to be adjusted
or the section 2.2.3 paragraph needs to be adjusted.

A specification should not contradict itself.  (Yes, one part can
refer to a second part to modify it (from what it would specify in
isolation), but it needs to do that correctly.)


Daniel
-- 
(Plain text sometimes corrupted to HTML "courtesy" of Microsoft Exchange.) [F]