W3C home > Mailing lists > Public > www-xml-schema-comments@w3.org > July to September 2007

[Bug 3230] Atomic = not decomposable?

From: <bugzilla@wiggum.w3.org>
Date: Fri, 21 Sep 2007 03:30:59 +0000
To: www-xml-schema-comments@w3.org
Message-Id: <E1IYZEJ-0003yR-MD@wiggum.w3.org>


------- Comment #3 from davep@iit.edu  2007-09-21 03:30 -------
(In reply to comment #2)
> Coming back to this issue, I wonder if matters would be improved if we
> (a) changed the phrase "for purposes of this specification" in the
> first sentence of section, Atomic Datatypes, to speak instead
> of determining type validity, and (b) added a Note.

I think the atomicity of the primitive datatype values lies in the fact that
they are not constructable by any means we provide from simpler datatypes'
values (in the sense that lists and unions are so constructable).  Though in
that respect it seems odd that a union of atomic datatypes is not atomic.

> With the changes, the section as a whole would read:
> Atomic Datatypes
>     An ·atomic· datatype has a ·value space· consisting of a set of
>     "atomic" or elementary values.
>       Note: Atomic values are sometimes regarded, and described, as
>       "not decomposable", but in fact the values in several datatypes
>       defined here do have internal structure.  Except insofar as that
>       internal structure is appealed to in checking whether particular
>       values satisfy various constraints (e.g. upper and lower bounds
>       on a datatype), however, that internal structure is not
>       systematically exposed by this specification.

We maintain that equality and order are defined for datatypes for the
convenience of other users as well as Schema; we define equality and order for
those structured values in terms of the internal structure.  Therefore it seems
inappropriate to assert that the structure is only relevant to checking various
Schema constraints.

>                                                      Other
>       specifications which use the datatypes defined here may define
>       operations which attribute internal structure to values and
>       expose or act upon that structure.
>     The ·lexical space· of an ·atomic· datatype is a set of ·literals·
>     whose internal structure is specific to the datatype in question.

If we break off the first sentence by inserting the note, I think we should
break the remaining paragraph here.

>     There is one ·special· ·atomic· datatype (anyAtomicType), and a
>     number of ·primitive· ·atomic· datatypes which have anyAtomicType
>     as their ·base type·.  All other ·atomic· datatypes are derived
>     either from one of the ·primitive· ·atomic· datatypes or from
>     another ·ordinary· ·atomic· datatype.  No ·user-defined· datatype
>     may have anyAtomicType as its ·base type·.
> The prose from "The lexical space ..." through to the end is
> unchanged.
Received on Friday, 21 September 2007 03:31:03 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:50:06 UTC