(In reply to comment #0)
> QT approved comment:
> 
> In 3.2.1, the initial definition correctly refers to "the set of all lists",
> while section 3.2.1.1 incorrectly refers to "all sets of lists". [The union of
> all sets of lists is a powerset.] 

The union of all sets of lists is a set of lists, which is what we want.  To
coin some in-line notation (read ';' as "subject to the condition"), in 3.2.1
we specified:

    ( U x ; (x a primitive datatype) (value space of x) ) u { x ; x is a list }

or equivalently:

    ( U x ; (x is a primitive datatype's value space ) x u { x ; x is a list }

In 3.2.1.1 we probably were thinking of:

    U x ; (x is a primitive datatype's value space or x is a set of lists) x

The comma changed the meaning, and in any case we might make the two parallel
or perhaps remove one.

I have no problem with the wording you prefer, but I think I take
issue with the claim that the existing wording in 3.2.1.1 is 
incorrect.  The union of any number of sets of X is itself
a set of X; a powerset is not the union but the set of some
sets.  3.2.1.1 says that the value space of anySimpleType is
the union of 

  - all of the primitives (i.e. all of the sets of
    atomic values), and 
  - all of the sets of lists formed from atomic values

Since the union of all sets of lists and the set of all lists
are (at least in this instance) the same, and the phrase
"the set of all lists" seems not to tempt the reader into
thinking of power sets, I'm happy to adopt the change.

I'm marking this editorial because I don't think there's any real
question in the WG about what is intended.

To make the wording proposal easier to review, I repeat it in more
verbose form here.  Delete the current first and only paragraph of
3.2.1.1, which now reads:

    The ·value space· of anySimpleType is the union of the ·value
    spaces· of all the ·primitive· datatypes defined here, and of all
    sets of lists formed from the members of the ·primitive·
    datatypes.

Replace it with this reformulation, which changes "and of all sets of
lists" with "the set of all finite-length lists".

    The ·value space· of anySimpleType is the union of the ·value
    spaces· of all the ·primitive· datatypes defined here, and of the
    set of all finite-length lists formed from the members of the
    ·primitive· datatypes.

Also change the definition of anySimpleType by replacing the phrase
"the set of all lists" with the phrase "the set of all finite-length
lists", the phrase "of all members" with "of members", and the phrase
"of all the primitive datatypes" with "of the primitive datatypes", so
that it reads:

    [Definition:] The definition of anySimpleType is a special
    ·restriction· of anyType.  anySimpleType has an unconstrained
    ·lexical space·, a ·value space· consisting of the union of the
    ·value spaces· of all the ·primitive· datatypes and the set of all
    finite-length lists of members of the ·value spaces· of the
    ·primitive· datatypes.

Note that this wording proposal is intended to resolve bug 3244 only;
it is not intended to resolve any other of the outstanding issues
about the definition of the special types, such as bug 3243, bug 5058,
or bug 3025.  The question of cleaning up the quantifiers, raised
here, is orthogonal to the questions raised in those other bugs.

I'm setting the status of this issue to needsReview; but note that
this wording proposal has not had the normal full editorial review.

Looking good. But one minor quibble (or rather, two). In

the set of all finite-length lists formed from the members of the ·primitive· datatypes.

(a) is "formed from" clear?

(b) is "members" clear?

(and in particular, is there any danger that anyone could misread this as suggesting the items in a list must all belong to the same primitive type?)

(I'll avoid reopening the discussion on "finite-length" as I'm in danger of shooting myself in the foot...)

Would the following be better:

the set of all finite-length lists of ·atomic values·

and then taking care to define atomic value (we almost do so already, but not quite).

(In reply to comment #3)

> Note that this wording proposal is intended to resolve bug 3244 only;
> it is not intended to resolve any other of the outstanding issues
> about the definition of the special types, such as bug 3243, bug 5058,
> or bug 3025.  The question of cleaning up the quantifiers, raised
> here, is orthogonal to the questions raised in those other bugs.

Since the existing wording is technically correct, even if someone did misread it, and bug 5058 points out that the definition of anySimpleType used here conflicts with the definition of value space, there is no point in trying to improve the wording here until we decide whether it is correct or the definition of value space is correct.  The WG should not spend time on this until 5058 is decided.

I suggest we modify the wording proposal of comment #3 by adopting the
changes suggested in comment #4, and also try to recast the
definitions in light of Sandy Gao's comment at the face to face
meeting that it feels odd to define the base type in terms of its
restrictions instead of vice versa.  (There is a limit to how fully I
have been able to address SG's concern, but I've tried.)

Net result:

1) In section 2.4.1, define atomic value and recast the definitions of
atomic and list datatypes to exploit it (and to align with the WG's
decision on bug 3230).  Specifically, for

    First, we distinguish ·atomic·, ·list·, and ·union· datatypes.

      - [Definition:] Atomic datatypes are those having values
        treated by this specification as indivisible.  Atomic
        datatypes are anyAtomicType and all datatypes ·derived· from
        it.

      - [Definition:] List datatypes are those having values each of
        which consists of a finite-length (possibly empty) sequence of
        values of an ·atomic· datatype (or a ·union· of ·atomic·
        datatypes), which is the ·item type· of the list.

read 

    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.

      - [Definition:] Atomic datatypes are those whose value spaces
        contain only atomic values.  Atomic datatypes are anyAtomicType 
        and all datatypes ·derived· from it.

      - [Definition:] List datatypes are those having values each of
        which consists of a finite-length (possibly empty) sequence of
        atomic values.  The values in a list are drawn from some 
        ·atomic· datatype (or from a ·union· of ·atomic·
        datatypes), which is the ·item type· of the list.

2) In 3.2.1, change the definition of anySimpleType, which currently
reads

    [Definition:] The definition of anySimpleType is a special
    ·restriction· of anyType.  anySimpleType has an unconstrained
    ·lexical space·, a ·value space· consisting of the union of the
    ·value spaces· of all the ·primitive· datatypes and the set of all
    lists of all members of the ·value spaces· of all the ·primitive·
    datatypes.

to read

    [Definition:] The definition of anySimpleType is a special
    ·restriction· of anyType.  Its ·lexical space· is the set of all
    sequences of Unicode characters, and ·value space· includes all
    ·atomic values· and all finite-length lists of ·atomic values·.

3) In 3.2.1.1, replace the current first and only paragraph, which now
reads:

    The ·value space· of anySimpleType is the union of the ·value
    spaces· of all the ·primitive· datatypes defined here, and of all
    sets of lists formed from the members of the ·primitive·
    datatypes.

with this reformulation:

    The ·value space· of anySimpleType is the set of all atomic values
    and of all finite-length lists of atomic values.


Note that this wording proposal has not had the normal full editorial
review.

Note also that as far as I can tell this proposal is compatible with
any of the proposed resolutions for the cluster of bug 3243, bug 3025,
and bug 5058.  Depending on how we resolve those issues, we should
probably add notes to 3.2.1 and 3.2.2 explaining how the value spaces
of anySimpleType and anyAtomicType relate to those of the primitives,
and how they stand on the question of effability.

The proposal in comment #6 looks good to me (who started all the fuss).

Michael Kay

(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".

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

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

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,  We refer to them differently; membership in the value spaces is conferred by intension, not extension, in our spec.  Thus the value spaces are not constructed using the value spaces of other datatypes.

Granted, at some point we have to stop nit-picking and credit our readers with intelligence.  ;-)

The XML Schema WG discussed this issue ("sets of lists") during our call of
26 October 2007.  We accepted the wording proposal of comment #6 and
instructed the editors mark the issue decided.  The amendment proposed in 
comment #8 was considered but not accepted; the arguments mentioned were that
it's better to define atomicity with respect to values not value spaces, and
the definition offered in comment #8 seems to be a definition of primitiveness,
not atomicity.  

Speaking personally, I am conscious that the latter argument also applies 
(albeit less strongly, I think) to the wording we accepted, and I continue 
to regard the definition of atomic value as a bit of a soft spot.  If a 
better formulation is found, we can and should consider it in a separate
later editorial proposal.

The WG decision mentioned in comment #9 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.  

As already indicated in comment #7, this solution looks fine. Thanks.