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: Kevin Braun <kbraun@obj-sys.com>
Date: Mon, 05 Oct 2009 10:19:02 -0400
Message-ID: <4ACA0056.7010501@obj-sys.com>
To: "C. M. Sperberg-McQueen" <cmsmcq@blackmesatech.com>
CC: www-xml-schema-comments@w3.org
I understand your point about trying to reference all of the changes.  
Very true.

Regarding eliminating the "flattening" of {member type definitions} (so 
as to now include member unions rather than recursively remove the 
unions by replacing with their members), my question (of the text) is 
what is the significance of that change?  Or, where does the 
specification make use of this change?  I finally came to figure out 
that, combined with of Type Derivation OK (Simple), 
this has an implication for type substitution.  I think it would be 
helpful if the description of the change mentioned that.  If there are 
other significant implications (I gather that is not the case), it would 
be helpful to mention them.

Perhaps that goes beyond the purpose of listing the changes, but it 
would be helpful to implementors.  I spent some time trying to figure 
out how the facets for a union restriction were being correctly enforced 
even when xsi:type was used to specify a member type, figuring there 
must be some new complicated rule somewhere that did that.  When I made 
the above discovery, I realized the truth of the matter.  A pointer to and a slightly better explanation (such as what you suggested) 
would have been more helpful to me.

I hope that helps.

On 10/2/2009 10:10 PM, C. M. Sperberg-McQueen wrote:
> 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
>   http://www.w3.org/XML/Group/2004/06/xsd-ed-pointers.html
> 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.
Received on Monday, 5 October 2009 14:24:44 UTC

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