- From: C. M. Sperberg-McQueen <cmsmcq@acm.org>
- Date: Fri, 26 Oct 2007 08:41:21 -0600
- To: bugzilla@wiggum.w3.org
- Cc: "C. M. Sperberg-McQueen" <cmsmcq@acm.org>, www-xml-schema-comments@w3.org
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