[Bug 12185] New: Conditional Type Assignment and substitutability

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

           Summary: Conditional Type Assignment and substitutability
           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


We have an "urgent feedback request" open on the rules concerning Conditional
Type Assignment and substitutability. This bug report responds to this request
for feedback.

First, note that there are no rules that constrain the use of elements with
conditional types in substitution groups. The following (test cta0041) is
entirely legal: <appendix> is substitutable for <chap> despite the fact that in
<chap type="dateTime"> the value is guaranteed to contain a timezone, while in
<appendix type="dateTime"> there is no such guarantee:

         <xs:complexType name="dateWithTypeAttribute">
            <xs:simpleContent>
                <xs:extension base="xs:date">
                    <xs:attribute name="type" type="xs:NCName"/>
                </xs:extension>
            </xs:simpleContent>
         </xs:complexType>

         <xs:complexType name="dateTimeStampWithTypeAttribute">
            <xs:simpleContent>
                <xs:extension base="xs:dateTimeStamp">
                    <xs:attribute name="type" type="xs:NCName"/>
                </xs:extension>
            </xs:simpleContent>
         </xs:complexType>

         <xs:complexType name="dateTimeWithTypeAttribute">
            <xs:simpleContent>
                <xs:extension base="xs:dateTime">
                    <xs:attribute name="type" type="xs:NCName"/>
                </xs:extension>
            </xs:simpleContent>
         </xs:complexType>

  <xs:element name="chap">
    <xs:alternative test="@type='date'" type="dateWithTypeAttribute"/>
    <xs:alternative test="@type='dateTime'"
type="dateTimeStampWithTypeAttribute"/>
  </xs:element>

  <xs:element name="appendix" substitutionGroup="chap">
    <!-- invalid restriction of the base type (not detected until validation
time) -->
    <xs:alternative test="@type='date'" type="dateWithTypeAttribute"/>
    <xs:alternative test="@type='dateTime'" type="dateTimeWithTypeAttribute"/>
  </xs:element> 

So, given a complex type definition B that allows <chap> within its content, it
is perfectly acceptable for an <appendix> to appear as a substitute for <chap>.

However, if I define a complex type R that restricts B, then within the content
of an element whose declared type is R, it seems I can no longer substitute an
arbitrary <appendix> for a <chap>: I am liable to fall foul of the "Conditional
Type Substitutable" rules.

Firstly, it seems illogical to impose a restriction on the second case but none
on the first. We should either require CTA type tables to be consistent in both
cases, or in neither.

Secondly, the current rule is very tough to implement without imposing a
significant overhead on run-time validation performance; and it's very
unsatisfactory that problems with the schema should be detected during instance
validation.

I would argue in favour of removing the restriction entirely. The impact of
this would be that processors can no longer draw inferences by examining the
type table: when the type table says that an event with location="GB" will have
a time-with-timezone, they cannot take this as an invariant that applies to all
subclasses. If you want to make this an invariant, you need to make it an
assertion. Making this change would remove a lot of complexity with (in my
view) very little loss of useful functionality.

An alternative which I could also accept would be to insist that when
subtyping, the type tables must be the same. This brings the rule into line
with Element Declarations Consistent, where we appeal to "sameness" of type
tables. This is a bigger loss of functionality, but in practice I find it hard
to see many people being affected by it.

-- 
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 Friday, 25 February 2011 13:33:43 UTC