[Bug 5244] Move co-constraints into types

http://www.w3.org/Bugs/Public/show_bug.cgi?id=5244

           Summary: Move co-constraints into types
           Product: XML Schema
           Version: 1.1 only
          Platform: Macintosh
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Structures: XSD Part 1
        AssignedTo: cmsmcq@w3.org
        ReportedBy: xan.gregg@jmp.com
         QAContact: www-xml-schema-comments@w3.org


The placement of co-constraints (aka type alternatives) in the element
declaration components instead if within type definitions seems to be an
ineffective end run around the derivation constraints of the type hierarchy.
"Ineffective" because elements declarations are also subject to derivation
constraints via substitution groups. See bug 5079.

Assume derivation constraints must be dealt with, why not put the
co-constraints in the type? Then they could be more readily shared by different
elements.

How to put co-constraints into type definitions? The mechanism could be
switching from the current type alternatives to content model alternatives. Or
there could be a new content type for constrained types.

For instance,

<xs:complexType name="message" base="messageTypeAny">
 <xs:alternativeContent>
  <xs:alternative test="@kind='string' type="messageTypeString"/>
  <xs:alternative test="@kind='base64' type="messageTypeBase64"/>
  <xs:alternative test="@kind='binary' type="messageTypeBase64"/>
  <xs:alternative test="@kind='xml'    type="messageTypeXML"/>
  <xs:alternative test="@kind='XML'    type="messageTypeXML"/>
 </xs:alternativeContent>
</xs:complexType>

How about those derivation constraints? Now they can't be avoided. It's
impractical, if not impossible, to determine if one general XPath test subsumes
another, but very constrained derivations could be allowed. 

For instance, each content alternative type must be a restriction of the base
type and if the base type has alternatives, then each derived alternative must
be a restriction of its *corresponding* base alternative. Alternatives
*correspond* if the base test is "A" and the derived test is "A" or "A and B".
If a derived test doesn't match a base test in that way, then it *corresponds*
to the default alternative in the base.

Received on Sunday, 4 November 2007 15:21:24 UTC