W3C home > Mailing lists > Public > www-xml-schema-comments@w3.org > October to December 2005

1.1 Structure suggestion: union of complex content

From: Thomson, Martin <Martin.Thomson@andrew.com>
Date: Wed, 5 Oct 2005 00:32:54 -0500
Message-ID: <AF9FCF3C02DB264EAF9872DFB6040FCC0CBBF20C@aopex5.andrew.com>
To: <www-xml-schema-comments@w3.org>
A pie-in-the-sky sort of suggestion for XML Schema 1.1...

One limitation of XML Schema is that the definition of cross dependencies between attributes and elements is not possible (correct me if I am wrong).  For instance, the element content in the following fragments cannot be validated differently based on the value of the type attribute:

  <thingy type="integer">1</thingy>
  <thingy type="boolean">true</thingy>
  <thingy type="string">string</thingy>

My suggestion is to allow for unions in complex type definitions.  My current thought is that they would operate in a similar fashion to simple type unions, at the same level as <restriction> or <extension>:

  <complexType name="tns:thingyType">
      <union base="tns:baseThingyType" memberTypes="#restriction"/>

  <complexType name="thingyType">
      <extension base="string">
        <attribute name="type" type="string" use="required"/>

Based on this definition, as long as instances are valid restrictions of tns:thingyType, the document would be valid.  The memberTypes attribute would be the union of "#any", "#restriction", "#extension" and the QName type (one or two hashes doesn't matter - I can't discern which is more appropriate here, the pattern is hard to pick).

A valid restriction of this type would consist of valid restrictions of any of the allowed types, or a smaller set of allowed types.

The idea of having a base type is that the construct could be substituted with the base type without any adverse effect, consistent with the restriction function.

Basically, this would enable cross-correlation of element and attribute content, also enabling restriction of attribute sets.  It's not as elegant as RelaxNG, but I think that it fits with the existing framework, with little actual work required.


This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
Received on Wednesday, 5 October 2005 05:33:03 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:50:04 UTC