W3C home > Mailing lists > Public > www-xml-schema-comments@w3.org > October to December 2009

Re: [Bug 7796] New: Misleading statement on change to unions

From: C. M. Sperberg-McQueen <cmsmcq@blackmesatech.com>
Date: Fri, 2 Oct 2009 20:10:12 -0600
Cc: "C. M. Sperberg-McQueen" <cmsmcq@blackmesatech.com>, Kevin Braun <kbraun@obj-sys.com>
Message-Id: <6BCCE50D-F767-4A0B-B28F-C45E06773F53@blackmesatech.com>
To: www-xml-schema-comments@w3.org

On 2 Oct 2009, at 09:37 , bugzilla@wiggum.w3.org wrote:

> http://www.w3.org/Bugs/Public/show_bug.cgi?id=7796
>           Summary: Misleading statement on change to unions
>           Product: XML Schema
>           Version: 1.1 only
>          Platform: PC
>        OS/Version: Windows XP
>            Status: NEW
>          Severity: normal
>          Priority: P2
>         Component: Structures: XSD Part 1
>        AssignedTo: David_E3@VERIFONE.com
>        ReportedBy: kbraun@obj-sys.com
>         QAContact: www-xml-schema-comments@w3.org
>                CC: cmsmcq@blackmesatech.com
> In the "changes since" appendix:
> "An error in version 1.0 of this specification relating to the  
> construction of
> union types from other union types has been corrected. Unions may  
> now appear as
> members of other unions, and all restrictions of unions are  
> correctly enforced,
> even when xsi:type is used on an element to name a member of the  
> union."
> As I understand it, rather than having a correct enforcement of a  
> restriction
> on unions when xsi:type is used to name a member of the union, the
> specification prevents this.  Assuming that the restriction was not  
> pointless
> (it has some facets), by of Type Derivation OK  
> (Simple), none
> of the member types can be said to validly derive from the  
> restriction.  That
> makes using xsi:type to specify a member type illegal.

Quite correct; the paragraph would be slightly more accurate
if it said "... and all restrictions of unions are correctly
enforced; xsi:type may not longer be used, as in XSD 1.0, to
subvert restrictions of a union type."

> It would also be helpful to point to where the specification was  
> changed,

This is not feasible in the general case.  Some bugs or sets
of bugs are resolved in a compact well-localized set of changes,
while others require changes in enough different locations to
make it tedious to try to provide a list of section numbers.

Those with member access to the W3C web site can examine the
specific change proposals adopted for specific bugs; in many
cases the change proposals are pointed to by comments in the
bug report, and even where this is not the case the proposal is
pointed to from the document at


In this particular case (bugs 2044 and 2333), the change
proposals involved changes in nine sections of Datatypes and
six sections of Structures; this editor (at least) thinks
the effort required to list them all in the appendix would be
out of all proportion to the potential benefit to readers.
(I may be missing something here; I don't actually see any
benefit to readers in the first place.)

> or
> what the implications of getting rid of flattening for {memberTypes}  
> are (see
> for example, bug 2233).

I'm sorry, but it's not clear to me what you mean here.

> Was it only to prevent a memberType from being
> considered as deriving from a restriction?

The WG requires, in order to make a change in the spec, that
there be (rough) consensus in the WG in favor of the change.
The WG does not, in general, require in addition that there be
consensus on the reason to make a change.  It is not uncommon
for one member of the WG to believe a change is necessary
to fix a bug, and another to believe that no such bug exists
but that the change is desirable in any case.  So I don't
want to commit myself to any explanation involving a word
like "only" and claiming to explain why the WG made a
particular decision.

I believe (without spending more time than I already have,
checking the decision record) that the change was made to
resolve bugs 2044 and 2333, which relate to the unintentional
loss of union-level facets when xsi:type is used to select
a particular member type.  But speaking for myself, I think
that XSD 1.1 gains in simplicity by eliminating 1.0's ad hoc
prohibition on unions as member types of unions, so that
I would have favored the change in any case.  The specific
bug relating to lost union facets is just one example of
the way fate punishes non-orthogonal designs.  I believe that
at least some WG members would be unmoved by the appeal
to orthogonality and were persuaded to make the change only
by the presence of the concrete bug.  I do not have a good
sense of how the members of the group were distributed
between and around those two positions.

* C. M. Sperberg-McQueen, Black Mesa Technologies LLC
* http://www.blackmesatech.com
* http://cmsmcq.com/mib
* http://balisage.net
Received on Saturday, 3 October 2009 02:10:44 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:50:10 UTC