(In reply to comment #0)
> We need to clarify whether the term 'constructed' is 
> used only in cases of immediate construction or 
> transitively.  

The definition in datatypes SQ is not transitive.  No
reason of which I'm aware would prevent changing
it, however.

On the telcon:
We have reached phase 1 agreement. Constructed is transitive. Part 2 will use "immediately constructed" as necessary for the non-transitive relation. 

Here is a concrete proposal to resolve this issue.  In Part 1
(Structures), change the definition of 'eligible item set' which forms
part of the description of how the ID/IDREF table is constructed.  In
the Last Call draft of Structures, the definition reads:

    [Definition:] Let the eligible item set be the set consisting of
    every attribute or element information item for which all of the
    following are true:

      1 its [validation context] is the ·validation root·;

      2 its [schema actual value] is not ·absent· and its [type
        definition] is the built-in ID, IDREF or IDREFS simple type
        definition or a type constructed from one of them;

      3 if it is an element information item, then clause 3.2 of
        Element Locally Valid (Element) (§3.3.4) does not apply.

The proposal is to change the wording of clause 2 in this definition, so
that it reads:

      2 its [schema actual value] is not ·absent· and its
        ·governing· type definition is the built-in simple type
        definition for ID, IDREF, or IDREFS, or a simple type
        definition derived or constructed directly (in a single
        derivation step) or indirectly (through one or more steps)
        from any of these;

Several points should probably be made explicitly.

(1) This proposal (change Structures, not Datatypes) is the reverse of
the Working Group's phase-1 decision of 24 August.  

(2) Datatypes applies the term 'constructed' to simple type
definitions many times.  In some usages, it makes no difference
whether 'constructed' is taken transitively or intransitively.
For example, in the phrase 'constructed datatype', defined by
2.4.2 thus:

      Next, we distinguish ·special·, ·primitive·, and ·ordinary· (or 
      ·constructed·) datatypes.

In some usages, the transitive interpretation of 'constructed' would
not lead to a logical contradiction, but it would work against the
grain of the sentence and it would be advisable to recast the sentence.
For example, in 2.4.2

    ·Ordinary· datatypes can be understood fully in terms of their
    Simple Type Definition and the properties of the datatypes from
    which they are ·constructed·.

Note in passing that simply replacing 'constructed' with 'immediately
constructed' would not heal the sentence, since it directs the
reader's attention toward the distinction between direct and indirect
construction and away from the point of the sentence.

In other usages (I collected eight before I stopped; that may be all
of them), the transitive interpretation would simply be wrong, and
recasting the sentence would be not merely advisable but essential.
In most of these cases, I don't see an obvious simple reformulation
that works.  For example in 2.4.3:

    By 'construction' is meant the creation of a datatype by defining
    it in terms of another.

Or in 2.4.1.3:

    Union types may be defined in either of two ways. When a union
    type is ·constructed· by ·union·, its ·value space·, ·lexical
    space·, and ·lexical mapping· are the "ordered unions" of the
    ·value spaces·, ·lexical spaces·, and ·lexical mappings· of its
    ·member types·. When a union type is defined by ·restricting·
    another ·union·

(3) Structures, as far as I can tell, uses the word 'constructed' of
simple types exactly three times.  Twice, immediate construction is
clearly required, although a recasting of the sentence would be
feasible: in section 3.16.6, in the rule Derivation Valid
(Restriction, Simple), clause 2.2 reads in part:

     The first case above will apply when a list is constructed by
     specifying an item type, the second when derived by restriction
     from another list.

And clause 3.1 is similar:

     The first case above will apply when a union is constructed by
     specifying one or more member types, the second when derived by
     restriction from another union.

The third use of 'constructed' to refer to simple type definitions is
in the definition of the eligible item set quoted at the beginning of
this comment.

(4) My proposal to reverse the polarity of the Working Group's
decision of 24 August is based on the observation that it's less work
this way, and the result is better.

On the telcon of 21 September 2007, the XML Schema WG adopted the proposal in 
comment #3 as a resolution of this issue.  We also decided that since the issue 
was resolved by changing Structures, not Datatypes, the issue should be 
reclassified as a Structures issue.

Accordingly, I'm changing the record of this issue as described.

Since the issue was raised by the WG itself, I'll also close it as soon as the
system lets me do so.