This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
I can find no specification of which facets are allowed for unions. Do they inherit the union of the allowed facets of their member types? Or the intersection? Or what? (By comparison, each special and primitive datatype has its specified list of allowed facets and all lists have the same specified list of allowed facets.)
Section 4.1.5 of the status-quo draft reads in part: If {variety} is union, then the applicable facets are pattern and enumeration. But it seems clear that if you looked and did not find the information you were looking for, we may need to mention it in another place. Would the definition of 'union' in 2.4.1 be an appropriate location for a recapitulation? (Perhaps a second note, after the one about what kinds of types can be member types?)
(In reply to comment #1) > Section 4.1.5 of the status-quo draft reads in part: > > If {variety} is union, then the applicable facets are > pattern and enumeration. Thank you. Since the only applicable facets are pattern and enumeration, then if the proposed solution to bug 2947 is adopted, it seems inappropriate to define order for unions when for primitives we only define order for those primitives that accept order-requiring facets. > Would the definition of 'union' in 2.4.1 > be an appropriate location for a recapitulation? (Perhaps > a second note, after the one about what kinds of types can > be member types?) Compare the paragraph after the second example in 2.4.1.2, which states explicitly which facets are available for lists. We should have a comparable statement in 2.4.1.3 for unions. I suspect I'm not the only reader who, seeing the list statement, would expect a similar statement in a similar location for unions. And especially readers who aren't just using the datatypes for Schema won't think to look in that "structures stuff". ;-)
When is a union ordered? The definition of ordered says that it is ordered if there is a single primitive datatype from which all of the union's basic member types are derived. OTOH, the specification of the {value} of the ordered fundamental facet is much looser, and in fact gives the (decimal union string) datatype the ordered {value} PARTIAL, even though the union is by definition not ordered. The WG had best resolve this. It's my gut feeling that the WG intended to follow the definition, and further to allow unions that were ordered by that definition to have the {min/max}{In/Ex}clusive facets apply. But that's just a vague gut feeling unsupported by any minutes. Maybe it's just wishful thinking, because that's the way I think we should go.
The minutes of the XML Schema WG call of 2 November 2007 (http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2007Nov/0010.html) [member-only link] show that the WG concluded that while the original intention was, or may have been, to allow upper- and lower-bounds facets on totally ordered unions (i.e. with all members from the same totally ordered primitive), it's clear that XSD 1.0 failed to achieve that. We also concluded that we don't want to try to go there now. The editorial task here, then, is to make it easier to find the list of facets applicable to unions. I'm changing the 'severity' field of this record to reflect the relative simplicity of this task.
A wording proposal intended to resolve this issue is on the W3C server at http://www.w3.org/XML/Group/2004/06/xmlschema-2/datatypes.b5062.html (member-only link)
I'm sorry if I'm being dense here, or if I have failed to recall the WG discussion that led us here. The effect of this proposal seems to be that union(decimal, string) is an ordered type but all the operations that normally apply to ordered types are disallowed. So why exactly are we saying that it is ordered? The stated justification, that making it unordered would be an "unmotivated and ad-hoc change" seems rather weak - if no ordering operations are available, it seems quite unreasonable to describe the type as ordered. The justification that facets such as minInclusive etc are disallowed "for compatibility with version 1.0" also seems curious. I can't see how allowing such facets would introduce an incompatibility. Using "for compatibility" as a justification generally means "we got it wrong last time and we're now stuck with it" - this doesn't seem to apply here. If we choose to give a reason for our decisions (we don't have to) then the reason had better be defensible.
At its telcon on 2008-03-14, the XML Schema WG adopted the wording proposal at http://www.w3.org/XML/Group/2004/06/xmlschema-2/datatypes.b5062.html (member-only link), and believes this issue now to be resolved. Since the originator of this issue is a WG member, he is presumed to assent to this resolution of the issue. For formal purposes, however, it would be convenient if he so indicated in the usual way.