This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The definition in part 2, section 2.4.1.3, states: [Definition:] The datatypes that participate in the definition of a ·union· datatype are known as the member types of that ·union· datatype. This doesn't say what the member types of a union derived by restriction from another union are. It also begs the question of what the "definition" is: is this referring to schema documents or schema components? For consistency, it would be best to make this term consistent with {member type definitions} in the component model - ideally by using only one term.
RESOLVED: instruct the editors to prepare a proposal along the lines suggested.
Proposal: after the definition of 'member types' add the following note: NOTE: when datatypes are represented using XSD schema components, as described in 4 Datatype copmonents, the member types of a union are those simple type definitions given in the {member type definitions} property. MK asks: This doesn't say what the member types of a union derived by restriction from another union are. It also begs the question of what the "definition" is: is this referring to schema documents or schema components? I take this passage (and indeed most of the Datatypes spec) to be talking neither about schema documents nor about schema components, but about datatypes more generally. A union has member types, and a transitive membership, whether it is being used in an XSD schema (which has schema components and usually has schema documents) or in a Relax NG schema (which does not have schema components as defined by XSD) or in some other context. MK's point about consistency is a good one, but I am reluctant to eliminate the term 'member type' and even more reluctant to define it in terms of the {member type definitions} property (which would better be defined in terms of member types). I think it is here probably more important to maintain consistency with and within the rest of Datatypes, which is making an effort (not, to be sure, always equally successful) to define a conceptual apparatus for simple types which is usable independently of XSD part 1. But perhaps I'm just rationalizing my deep desire not to make a change that would involve touching a dozen passages of the document. Adding this simple note is quick and easy; making the change MK suggests is tedious, error-prone, and slow. Quick is good. Easy is good.
(In reply to comment #2) FWIW, I concur.
Perhaps it might be better also to change "The datatypes that participate in the definition of a ·union· datatype..." to "The datatypes that contribute to the value space of a ·union· datatype..."? The problem with "participate in the definition" is that for a union type defined by restriction, we appear to say that the base type is a member type of the union, because it participates in its definition.
(In reply to comment #4) > Perhaps it might be better also to change "The datatypes that participate in > the definition of a ·union· datatype..." to "The datatypes that contribute to > the value space of a ·union· datatype..."? > > The problem with "participate in the definition" is that for a union type > defined by restriction, we appear to say that the base type is a member type of > the union, because it participates in its definition. I like MK's proposal, because I like one side effect that should not be adopted without reailzing it: The "datatypes that participate in the definition" presumably are those that go into the (possibly ancestor) union definition may have all their values removed from the union data space, but presumably these datatypes remain member types of the restricted union under this definition. OTOH, if all of such a datatype's values have been removed by subsequent restriction, they surely "no longer contribute to the value space" of the restriction.
RESOLVED: adopt proposal in comment #2 but with "When" instead of "when".
This bug should be resolved in the CR at: http://www.w3.org/TR/xmlschema11-2/ The WG appreciates the effort of the commenter in reporting this bug. Please indicate your satisfaction with the resolution by marking it as CLOSED. Thank you.