You are of course correct.  A good principled definition of atomicity
seems elusive, so fixing this appears to require non-trivial editorial
ingenuity.  Reviewing some literature on the relational model, I 
wonder whether it would be better not to say that the values are
atomic, or not decomposable, but only that they are treated as such
in the framework of schema-validity assessment.  (It would be too much
to say "treated as atomic by this specification", because of course
the seven-property model of dates and times explicitly treats the
values of numerous types as tuples.)

A more formal response on behalf of the working group will follow, when
we have approved a wording change, or when the editors have torn all
their hair out and given up.

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 2.4.1.1, Atomic Datatypes, to speak instead
of determining type validity, and (b) added a Note.

The first sentence now reads:

    An ·atomic· datatype has a ·value space· consisting of a set of
    "atomic" values which for purposes of this specification are not
    further decomposable.

With the changes, the section as a whole would read:

    2.4.1.1 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.  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.
    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.

(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 2.4.1.1, 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:
> 
>     2.4.1.1 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.
> 

From the telcon on 2007-09-24 (Editors' call)


<MSM> on 3230, delete sentence "Except ... specification" and insert "       , which is appealed to in checking whether particular values
<MSM>        satisfy various constraints (e.g. upper and lower bounds on a
<MSM>        datatype).
<MSM> "

From the Editor's call 2007-09-24:
<MSM> MSM converges on:
<MSM>     2.4.1.1 Atomic Datatypes
<MSM>     An ·atomic· datatype has a ·value space· consisting of a set of
<MSM>     "atomic" or elementary values.
<MSM>       Note: Atomic values are sometimes regarded, and described, as
<MSM>       "not decomposable", but in fact the values in several datatypes
<MSM>       defined here do have internal structure, which is appealed to in
<MSM>       checking whether particular values satisfy various constraints
<MSM>       (e.g. upper and lower bounds on a datatype).  Other
<MSM>       specifications which use the datatypes defined here may define
<MSM>       operations which attribute internal structure to values and
<MSM>       expose or act upon that structure.
<MSM>     The ·lexical space· of an ·atomic· datatype is a set of ·literals·
<MSM>     whose internal structure is specific to the datatype in question.
<MSM>     There is one ·special· ·atomic· datatype (anyAtomicType), and a
<MSM>     number of ·primitive· ·atomic· datatypes which have anyAtomicType

The editors have converged on text slightly different from the wording
given in comment #5, namely:

    2.4.1.1 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 are described with internal structure,
        which is appealed to in checking whether particular values
        satisfy various constraints (e.g. upper and lower bounds on a
        datatype).  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.

    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·.

This wording is now ready for review by the Working Group.

decided by wg this date

decided by wg this date; as shown in previous comment

The change outlined in comment #6 and approved in September 2007 was
integrated into the status-quo document in October 2007.  (That fact should
have been noted here earlier, but there were distractions.)

Michael, as the individual who entered the issue on behalf of QT, 
could you at some convenient point report the WG's disposition of the 
issue back to QT and let us know in the usual way whether QT is content
with that disposition or not, by changing the status either to CLOSED
or to REOPENED?  Thank you.  

I think this is as good as we're going to get, so I'm closing it. Thanks.