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

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

-- 
****************************************************************
* C. M. Sperberg-McQueen, Black Mesa Technologies LLC
* http://www.blackmesatech.com
* http://cmsmcq.com/mib
* http://balisage.net
****************************************************************

Received on Friday, 5 February 2010 19:43:18 UTC