Re: [Bug 3244] Sets of lists

On 26 Oct 2007, at 07:54 , bugzilla@wiggum.w3.org wrote:

> http://www.w3.org/Bugs/Public/show_bug.cgi?id=3244
>
> ------- Comment #8 from davep@iit.edu  2007-10-26 13:54 -------
> (In reply to comment #6)
>
>>     First, we distinguish ·atomic·, ·list·, and ·union· datatypes.
>>
>>     [Definition:] An atomic value is an elementary value, not
>>     constructed from simpler values by any means defined by this
>>     specification.
>
> Since we have been nit-picking the definitions, it seems to me that  
> the
> prescriptions of built-up primitive datatypes (e.g., date/time  
> datatypes,
> duration, and precisionDecimal) could be construed as "means  
> defined by this
> specification".

It can, I agree.  I was not able to find any good words that
did not allow the reader at least to ask the question "well,
but surely you define how the instances of the seven-property
model are built up, isn't that 'means defined by this spec'?".
The most one can claim for the proposal in comment #6 is that
a reasonable reader may be able to decide, without too much
trauma, that while our spec does indeed say how such values
are built up out of simpler values, it does so by a means
(namely tuples, in the loose sense of the word popularized by
RDBMS) which this spec appeals to but does not define.

And, of course, the note we have agreed to add to the section on
atomic datatypes also helps clarify the issue, for a reader
who reads it.

If anyone has words that do the job better and don't have other
problems I'll be happy to adopt them.

> Is the important point that an atomic *datatype* cannot be  
> constructed from
> simpler *datatypes* by any means defined in this specification?   
> (And then, of
> course, atomic values are values in the value space of an atomic  
> datatype.)

That's for the WG to decide, of course; my view is that no, the
important point is about values, not about value spaces.

>> - [Definition:] Atomic datatypes are those whose value spaces
>>         contain only atomic values.  Atomic datatypes are  
>> anyAtomicType
>>         and all datatypes ·derived· from it.
>
>     - [Definition:]  Atomic datatypes are those which cannot be  
> constructed
>       from simpler datatypes by any construction mechanism defined in
>       this specification.

The inability to construct some X in terms of other things defined
is what I think normally leads one to describe X as primitive, not
necessarily as atomic.  That our primitive datatypes are all
atomic is an extensional fact, but not, I think, an intensional one.

> While we construct the built-up datatypes using objects with named  
> properties
> whose values are generally real numbers (specifically decimals and  
> integers) or
> strings of characters, these values are not "members of the value  
> space" of the
> corresponding datatypes,

?! I do not believe we have agreement on this, as regards decimals
or the integers.  It's true of float and double that the WG gave
up on trying to define a real-number type, during the development of
1.0.  If we have ever made a design decision that the value space
of integers contains not the integers but representations of the
integers, which is what you seem to be saying here, then the decision
slipped past me without my realizing it, and I am inclined to object
strenuously.

Michael

Received on Friday, 26 October 2007 14:41:30 UTC