(In reply to comment #0)

> (a) the indentation of the Note is curious. It is different from the
> indentation of the immediately following notes, which suggests, I think
> wrongly, that it is relevant only to the final clause of the constraint Type
> Derivation OK (simple).

I'm not prepared to comment on whether the Note *should* only apply to 2.2.4.3, but it is certainly coded in the source XML as being part of that clause; the other three Notes are not.

> (b) I'm not sure that in the case of the lexical mapping, the Note is actually
> true. Given a base type B defined as union(xs:string, xs:date), and the derived
> type D defined as xs:date, then the lexical mapping for D includes the mapping
> from 2010-10-10 to an xs:date, which is not present in the lexical mapping for
> B (because that string maps to a value in the value space of xs:string).

But it is in the mapping, because of Section 2.3.  See following.

> (However, I'm having considerable trouble interpreting section 2.3 here. On the
> one hand, it states that the lexical mapping for the type union(string, date)
> is not a function, since the same string is the lexical representation of
> values in both member types. On the other hand, the section says "Should a
> derivation be made using a derivation mechanism that removes ·lexical
> representations· from the·lexical space· to the extent that one or more values
> cease to have any ·lexical representation·, then those values are dropped from
> the ·value space·.", which, if it applieas to union(string, date) would seem to
> suggest that all dates are removed from the value space and therefore from the
> lexical mapping; it's hard to reconcile these two statements.)

No.  The whole point is that the lexical representations of dates in union(string,date) are mapped both to strings and to dates.  From 2.4.1:  "[Definition:]  Union datatypes are (a) those whose ·value spaces·, ·lexical spaces·, and ·lexical mappings· are the union of the ·value spaces·, ·lexical spaces·, and ·lexical mappings· of one or more other datatypes, which are the ·member types· of the union, or (b) those derived by ·facet-based restriction· of another union datatype."  Mappings are intended to be sets of ordered pairs.  Thus, a union cannot remove any ordered pairs from the mapping, hence cannot remove any strings/values from the lexical or value spaces.  The "derivation mechanism that removes lexical representations" rule that you mention refers to facets such as pattern which directly remove lexical representations.

It is true that if a date representation is encountered where your union applies, the representation will be associated with the string value (barring no other influence, such as an xsi:type attribute).  This is not because the other value has been removed, but because of the ramifications of 2.4.1.3 (q.v., especially the first few paragraphs and the definition of "active basic member").

As a matter of history, as best I can remember, this business of non-function lexical mappings was introduced to ensure that there was no magic involved whe xsi:type attributes were presentl.  If, e.g. in your union(string,date), an xsi:type attribute specified date, there needs to be a lexical mapping pair available that maps to a date.

Hope this helps.  (And I hope I haven't missed anything--it's getting late.   ;-)  )

I think this comment applies most directly not to Datatypes but to Structures; the text quoted appears in the latter but not the former.  But I'm not changing the component field.

On the indentation:  The note seems to me to be correctly attached to clause 2.2.4.3 of Type Derivation OK (Simple), because it is the requirement that B and any intervening unions have an empty {facets} property that guarantees the subset relations mentioned.  (If D is a basic member of B, but B has a pattern facet limiting it to strings of length 1, for example, then the subset relation does not apply.  My recollection is that the QT formal semantics makes certain plausible assumption about subset relations in restriction and in the use of xsi:type to choose an alternate basic member of a union; without this constraint those assumptions collapse like a dynamited smokestack.)  The note in question was added as part of a fix for bug 2333, which in turn is connected with bug 2044, about the loss of facet-based restrictions in unions.

On the truth of the note:  my understanding agrees with Dave Peterson's.  I'll add only that trying to tighten up the formal definitions in Datatypes to clear up questions like this one was one of our main goals in 1.1 work on Datatypes, and I think that the spec is relatively explicit that lexical mappings are not always functions (there is a reason they are not called lexical functions), that construction by union results in a lexical mapping which is the set union of the lexical mappings of the members, and that when the lexical mapping is not a function, specifications (including both XSD and the QT specs) may specify other means for choosing which member of the lexical mapping to use.  (For elements and attributes with union types, XSD specifies an order of preference matching the order in which members are listed in the {member type definitions} facet; for elements, XSD allows the use of xsi:type to override that default choice; QT provides a complicated set of promotion rules that choose values when several are mapped to.)

Thanks for the response Michael. It seems to be wishful thinking to believe we can make this area clear to the average reader...

The WG reported this bug as INVALID on 2010-10-15.  We are closing this bug as
requiring no futher work.  If there are issues remaining, you can reopen this
bug and enter a comment to indicate the problem.  Thanks very much for the
feedback.