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 specification currently uses the term "restricted union type" to mean, in effect, a union type that is not derived by restriction. This seems extremely confusing, since a reader could easily assume that it means exactly the opposite. I propose that the concept should be renamed "constructed union type", since a union type that is not derived by restriction is always derived by construction. The term doesn't capture 100% of the semantics, because it is also required that any union types among the member types of the union are also constructed union types, but it's much less likely to be misunderstood.
I've always disliked the term "restricted union type" for just this reason. Ideally, I'd like a name that evokes what is said in the definition: [Definition: A restricted union type is an XML Schema union type that satisfies the following constraints: (1) {variety} is union, (2) the {facets} property is empty, (3) no type in the transitive membership of the union type has {variety} list, and (4) no type in the transitive membership of the union type is a type with {variety} union having a non-empty {facets} property]. To me, the proposed name doesn't do that. I suppose the name should ideally say something like "no lists, no facets". To me, 'constructed' doesn't say that.
Current thoughts: 1. I think this is editorial. 2. I think we can change the term any time we come up with a good one. 3. Maybe we should bite the bullet and choose a wordy but descriptive term? [Definition: A *list-free and facet-free union type* is an XML Schema union type that satisfies the following constraints: (1) {variety} is union, (2) the {facets} property is empty, (3) no type in the transitive membership of the union type has {variety} list, and (4) no type in the transitive membership of the union type is a type with {variety} union having a non-empty {facets} property].
It depends what you mean by "editorial". If you mean, we can change this without affecting the syntax or semantics of the language, then yes it is editorial. If you mean, we can change this without involving the WG in the discussion, then no, I think the choice of formal terminology is more important than that. For example, the terms we use in the spec are likely to be reflected in text books and in error messages issued by products, and as such have a direct bearing on the usability of the language. Your proposed term feels unwieldy, and feels like an attempt to make the term self-explanatory, which seems doomed to failure (for example, it doesn't capture the fact that you can't have lists anywhere, but you can have facets at the level of an atomic type). It's also negative: it says what is outside the class rather than what is inside it. The essence of this kind of union type is that its value space is the mathematical union of the value spaces of one or more atomic types. I'm inclined to go for simple adjective that has no intrinsic meaning but that isn't already in use, and that reflects the fact that we're dealing with a subset of all union types that has very simple properties: perhaps a "pure union". I'd stlll like to leave "constructed union" on the table, however.
The WG has decided on the term "pure union type".