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

I can't speak for the group, but it doesn't seem to me that there's an 
obvious analog for quite the xs:alternative facility that would apply to 
an individual attribute.  What alternative says is, in essence: you can 
select a type to be used to validate an element -- the type selected is a 
function of the attributes of that element.  So, roughly, you can test for 
the occurrence and/or values of the attributes on an element, and use that 
to select a type to be used to validate the element.   Note that the 
selection is a function of constructs that are part of the element itself; 
 no siblings, ancestors, etc. are consulted, and that's important to keep 
the whole thing relatively context-free.

Now, let's try to design a similar facility that would apply to selecting 
types for an attribute.  Consider the instance element:

        <e at1="A" at2="B" at3="B" />

The analogy to what's provided for elements would be to allow the 
declaration for, say, attribute at2 to select a type that's a function of 
.... what?  Well, at best that would be the occurrence and value of at2. 
But checking for the occurrence of at2 would be circular, since the 
declaration of attribute a2 is consulted only if at2 exists.  That leaves 
us with the value of at2:  do we really want to dynamically select a type 
to validate the value of at2 based on the value of at2?  That seems like a 
lot of complexity:  if our capabilies for validating a single attribute 
value aren't sufficiently rich, I'd be tempted to enhance the capabilities 
of simple types, rather than introducing alternatives.  I believe that XSD 
1.1 now supports <assertions> on simpleTypes, and that might address some 
use cases.

One thing did surprise me in researching this:  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.  My 
memory of what we intended may be faulty.

Noah

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------








Maik Stührenberg <maik.stuehrenberg@uni-bielefeld.de>
Sent by: www-xml-schema-comments-request@w3.org
02/01/2010 07:28 AM
 
        To:     www-xml-schema-comments@w3.org
        cc:     (bcc: Noah Mendelsohn/Cambridge/IBM)
        Subject:        XSD 1.1: xs:alternative only allowed as child of 
xs:element?


Hello,

I've tried to search both W3C's bugzilla and mailing list archive
regarding the current state of the xs:alternative element introduced in
XSD 1.1 finding an answer to a question that bothers me (without success
up to now -- hence this question):
Is there a reason why type alternatives (using xs:alternative) are only
allowed for element declarations? Maybe I'm just to blind to see but one
of the benefits of XSD 1.0 was that elements and attributes were (more
or less) handled equally (e.g. in terms of defaults).

It would be nice if anyone could give me just a quick hint which
circumstances have lead to this decision (either a mailing list
discussion or anything else).

Best regards,

Maik Stührenberg

Received on Thursday, 4 February 2010 22:17:24 UTC