This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Section 2.4.1 contains the Note It is a consequence of constraints normatively specified elsewhere in this document that any ·primitive· or ·ordinary· datatype may occur among the ·member types· of a ·union·. (In particular, ·union· datatypes may themselves be members of ·unions·, as may ·lists·.) The only prohibition is that no ·special· datatype may be a member of a ·union·. It would be helpful to the reader to have a pointer to where "elsewhere" is. In fact it's remarkably hard to find the rule that bans special datatypes from participating in a union (if it were easier, I suspect the editor would have included a link). (and the same is probably also true of the previous note concerning lists). For unions, seeking such a constraint: * Section 2.4.1.3 says, in the introductory prose, "Any number (zero or more) of ordinary or ·primitive· ·datatypes· can participate in a ·union· type." (But it doesn't actually say that special datatypes can't). * 2.4.2.3 says nothing * 4.1.1 says nothing * 4.1.5 says nothing Is there anywhere else I should have looked?
I believe that the sentence from 2.4.1.3 quoted in the description ("Any number ... of ordinary or primitive datatypes can participate in a union type") was taken by the WG and editors (together, perhaps I should say, with the absence of any corresponding statement allowing special datatypes to be members of unions) as providing the normative statement in question. It does seem odd to me that there is no constraint on components to enforce the rule. It would probably be helpful either to add a Constraint on Schema saying that if {variety } = union, then {member type definitions} should be a list of ordinary or primitive type definitions, or else to rephrase the description of {member type definitions} in the tableau, specifying that the members are primitive or ordinary. In the case of lists, I think the property identified in a note follows from the definition of list datatypes in the bullet item to which the note is attached and (also? independently? or jointly? not sure, my formal logic is feeling a bit fuzzy today) from the definition of item type in section 2.4.1.2 and the sentence following that definition. But here, too, I think an explicit constraint on schemas and/or rephrasing of the component tableau might be helpful.
Resolved: <dezell> MSM: class as "needsDrafting" instruction on 2 changes. <dezell> ...: 1) in Datatypes, put the rule in an appropriate place in the datatypes spec, <dezell> ...: 2) put in a note that explains that it applies outside of XSD <dezell> ...: 3) do in Structures, make Datatypes operate as a free-standing spec. <dezell> ...: rule = "dervation valid ..."
Approved on the telcon 2011-02-04
*** Bug 11336 has been marked as a duplicate of this bug. ***
For the record: the proposal approved 7 February is at http://www.w3.org/XML/Group/2004/06/xmlschema-1/structures.b11103.html http://www.w3.org/XML/Group/2004/06/xmlschema-2/datatypes.b11103.html (member-only links).
The change proposals mentioned in comment 3 and comment 5 have been integrated into the status-quo version of the spec, so this issue can be marked resolved. Michael, if you would check the resolution and close the issue, or reopen as needed, it would be helpful. Thank you.