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

Dave Peterson wrote:
> At 11:57 AM -0400 2009-09-02, Barclay, Daniel wrote:
> 
>>  >> 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."
> 
> Perhaps you jumped into the middle of the spec.  

Definitely.  I have read the schema specification in full before,
but this time I was referring to a piece of it to try to check a
particular thing.

For the specification to be usable for that type of use case
(without having to re-read the entire thing every time), it should
minimize the number of statements that appear to mean one thing
but really mean something else because they are modified by some
other statements.


 > You are quoting a
> paragraph from the discussion of order, but before order comes equality
> and before equality comes identity.  Since your complaint is about
> the apparent identity of values in the two binary-string datatypes,
> perhaps we should see what is said in the section on identity rather
> than order.  In 2.2.1 the spec says:
> 
>   In the identity relation defined herein, values from different
>   ·primitive· datatypes' ·value spaces· are made artificially distinct
>   if they might otherwise be considered identical.
> 
> Perhaps that more explicitly says what you are looking for.  

Yes, that seems to be a bit more explicit than the other paragraph.

However, it's not clear that it resolves the contradiction in the
wording.  "Otherwise" there is ambiguous:

If "otherwise" means "other than one might normally think,
_excluding_, of course, what one might think from what this
specification says" then that statement does _not_ actually modify
what sections 3.3.16.1 and 3.3.17.1 say, so they (not being
modified) combined with 2.2.1 make a contradiction, so something
needs to be modified.

If "otherwise" means "other than one might normally think,
_including_ what one might think from what this specification
says," then, since that is equivalent to saying "This statement is
false," interpretation falls apart, so obviously the "otherwise"
can't have been intended to mean that (and shouldn't be left
interpretable that way).

The "otherwise" might mean something else, but it's unclear what,
so it's ambiguous and clearly needs to be modified.

(The first case seems to be the only reasonable one.)


> Once
> we make that general statement, do we really need to reiterate it
> for every primitive datatype where there might be an overlap with
> another?

Probably not.  Certainly, it certainly does not need to be
reiterated if it is accounted for in the subsequent wording (i.e.,
if there's no apparent contradiction in the first place).
Hopefully it can be accounted for without being too verbose.

The OWL 2 draft specification (at
http://www.w3.org/TR/2009/CR-owl2-syntax-20090611/)
refers to XML Schema's setup using wording as in (underscore
emphasis added):

    According to XML Schema, the value spaces of xsd:hexBinary and
    xsd:base64Binary are _isomorphic_ _copies_ of the set of all
    finite sequences of octets ...

and:

   The value space of xsd:anyURI can therefore be seen as an
   "_isomorphic_ _copy_" of a subset of the value space of
   xsd:string.

Couldn't the XML Schema specification simply use some wording
pattern like that in the type detail sections (e.g., hexBinary's
3.3.16.1)?

Doing that would eliminate the contradiction.  It would eliminate
it at its source, which probably is the simplest solution.

(Certainly, it's better to simply have 2.2.1 say how things are
(disjoint spaces) and have all the detail sections back it up
(worded to define spaces disjointly) than to have 2.2.1 say how
things are, also say/imply that other wording has to be taken
differently than at face value, and have various detail sections
seem to contradict 2.2.1.)



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