[Bug 6545] New: Using Assertions to restrict complex types

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

           Summary: Using Assertions to restrict complex types
           Product: XML Schema
           Version: 1.1 only
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Structures: XSD Part 1
        AssignedTo: David_E3@VERIFONE.com
        ReportedBy: mike@saxonica.com
         QAContact: www-xml-schema-comments@w3.org
                CC: cmsmcq@blackmesatech.com


I've been writing a conference paper about XSD 1.1, and specifically about
assertions, and I hit a rather embarrassing usability problem. Sorry for
raising it at this stage of the game, but it's exactly at this stage that
usability problems tend to be discovered.

I was trying to show how useful assertions are in customizing a schema for
local use. For example, suppose there is a standard IPO schema for internal
purchase orders, and you want to customize it so that money amounts are always
in dollars. So one should be able to say:

<xs:element name="our-IPO">
  <xs:complexType name="our-IPO-type">
    <xs:complexContent>
      <xs:restriction base="IPO-type">
        <xs:assert test="every $c in .//@currency satisfies $c='USD'"/>
      </xs:restriction>
    </xs:complexContent>
  <xs:complexType>
</xs:element>

Simple, isn't it? But wrong. Applying xs:restriction to a complex type inherits
the attribute uses of the base type, but not the particle or the attribute
wildcard. If you want your restricted type to have the same content model as
the base type, you have to copy it across, in all its gory detail. And of
course every time it changes, your new type has to change too.

I've got a few ideas on how to fix this. I'll start with the one that I think
is best but most radical, which I'll call the Grand Plan.

The Grand Plan is to remove the assymmetry in complex type restriction as to
which parts of the base type definition are inherited and which are explicitly
redefined. (This is all at the XML representation level, the component level is
unaffected.)

To xs:restriction (for complex types) we add an attribute @inherit, whose value
is a list of tokens from the set (content, attributes, anyAttribute) or the
value #all to indicate all of the above. The default value, for compatibility
reasons, is "attributes". The @inherit attribute indicates which aspects of the
base type definition are inherited. If attributes are inherited, we allow
attributes to be redefined in the restricted type as at present, but if content
or anyAttribute is inherited, we require the restricted type to specify no
content or no attribute wildcard respectively.

Add the XML representation rule that if xs:restriction/@inherit includes
content, then the xs:restriction element must not have a sequence, choice, all
or group child; and if it includes anyAttribute, then it must not have an
anyAttribute child.

The mapping rule for attribute uses (3.4.2.4) is changed as follows: in 3.2,
change "If T is a complex type definition and {derivation method} =
restriction" to add " and the [inherit] attribute of the <restriction> element
includes 'attributes'"

The mapping rule for atribute wildcards (3.4.2.5) is changed as follows: rule
2.1, currently "If  {derivation method} = restriction  , then the ·complete
wildcard·;" becomes: 2.1 If {derivation method} = restriction, then the
relevant case among the following: 2.1.1 if the [inherit] attribute of the
<restriction> element includes 'anyAttribute' then the base wildCard 2.1.2
otherwise, the ·complete wildcard·. And promote the definition of "base
WildCard" from 2.2.1.

The mapping rule for complex content {content type} (3.4.2.3.3) is changed as
follows: in 4.1 ("4.1 If  {derivation method} = restriction") add the rule "If
the inherit attribute of the <restriction> element includes "content", then
{base type definition}.{content type}

That's the Grand Plan. If it's too much to stomach, can we get away with less?

Plan B: We could cut it down so the only new option is inherit="content".

Plan C: We could cut it down further so there is no new syntax, but
inherit="content" is implicit in the case of an xs:restriction that has an
xs:assert child but no xs:sequence|xs:choice|xs:all|xs:group child. Yuk.

Plan G: A different approach. We could introduce "manual inheritance" for
complex types by syntax such as:

<xs:element name="our-IPO">
  <xs:complexType name="our-IPO-type">
    <xs:complexContent>
      <xs:restriction base="IPO-type">
        <xs:group/>
        <xs:assert test="every $c in .//@currency satisfies $c='USD'"/>
      </xs:restriction>
    </xs:complexContent>
  <xs:complexType>
</xs:element>

where the absence of a "ref" attribute on xs:group means "an anonymous model
group corresponding to the content model of the base type". This is perhaps the
least disruptive proposal.

Plan H: Introduce special syntax for the case where a complex type is
restricted only by addition of assertions:

<xs:element name="our-IPO">
  <xs:complexType name="our-IPO-type">
     <xs:restriction base="IPO-type">
        <xs:assert test="every $c in .//@currency satisfies $c='USD'"/>
     </xs:restriction>
  <xs:complexType>
</xs:element>


-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Monday, 9 February 2009 10:12:10 UTC