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 18:18:13 UTC