Re: XSD 1.1: xs:alternative only allowed as child of xs:element?

Noah, Michael,

thank you both for your reply and explanations regarding the type
alternative in XSD 1.1.
Noah, I see the circularity problems you've discussed. It seems that I
misunderstood the type alternative feature, so thank you both a lot for
clarifying that issue.

Best regards,

Maik Stührenberg

Am 05.02.10 20:42, schrieb noah_mendelsohn@us.ibm.com:
> Terrific, thank you.  I wasn't particularly worried because I knew we had 
> intended to enforce the restriction, and it seemed the sort of thing that 
> would only have been changed for good reason.  FWIW, I believe I was 
> looking in the section on xs:alternative, and I infer from your note that 
> in fact it's with xs:element.  Thank you for the clarification.
> 
> Noah
> 
> --------------------------------------
> Noah Mendelsohn 
> IBM Corporation
> One Rogers Street
> Cambridge, MA 02142
> 1-617-693-4036
> --------------------------------------
> 
> 
> 
> 
> 
> 
> 
> 
> "C. M. Sperberg-McQueen" <cmsmcq@blackmesatech.com>
> 02/05/2010 01:17 PM
>  
>         To:     noah_mendelsohn@us.ibm.com
>         cc:     "C. M. Sperberg-McQueen" <cmsmcq@blackmesatech.com>, Maik 
> Stührenberg <maik.stuehrenberg@uni-bielefeld.de>, 
> www-xml-schema-comments@w3.org
>         Subject:        Re: XSD 1.1: xs:alternative only allowed as child 
> of xs:element?
> 
> 
> 
> On 4 Feb 2010, at 15:16 , noah_mendelsohn@us.ibm.com wrote:
>> ... I was fairly sure that
>> when we designed the xs:alternative mechanism it was required that 
>> each of
>> the alternative types for an element be derived from the explicitly
>> declared type;  I don't see that constraint enforced in the spec.
> 
> The schema component constraint Element Declaration Properties
> Correct in section 3.3.6.1 of the spec enforces the rule you are
> thinking of in its final clause:
> 
>      7 If E.{type table} exists, then for each {type definition}
>        T in E.{type table}.{alternatives}, and also for
>        E.{type table}.{default type definition}.{type definition},
>        one of the following is true
> 
>          7.1 T is ·validly substitutable· for E.{type definition},
>              subject to the blocking keywords of
>              E.{disallowed substitutions}.
>          7.2 T is the type ·xs:error·.
> 
> I hope this helps reassure you.
> 
> If one looks for this rule only in the section describing type tables
> (which does not seem an unreasonable place to look), one won't find
> it; it can't usefully be enforced on type tables in isolation, because
> it depends crucially on E.{type definition}, which is not part of the
> type table.  That's a consequence of the way the WG chose to integrate
> conditional type assignment with the existing design; a design less
> obsessively fixated on compatibility with every quirk and flaw of the
> 1.0 component layer would have been able to arrange things less
> confusingly.
> 
> 
> Michael
> 

-- 

Maik Stührenberg, M.A.

Universität Bielefeld
Fakultät für Linguistik und Literaturwissenschaft
Universitätsstraße 25
33615 Bielefeld

Telefon: +49 (0)521/106-2534
E-Mail: maik.stuehrenberg@uni-bielefeld.de

http://www.maik-stuehrenberg.de
http://www.xstandoff.net

Received on Monday, 8 February 2010 12:35:55 UTC