[Bug 5480] Substitution groups and 8.2.3.1.1

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

           Summary: Substitution groups and 8.2.3.1.1
           Product: XML Query Test Suite
           Version: unspecified
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: normal
          Priority: P2
         Component: XML Query Test Suite
        AssignedTo: andrew.eisenberg@us.ibm.com
        ReportedBy: nick@cbcl.co.uk
         QAContact: public-qt-comments@w3.org


Consider a schema:

<schema targetNamespace="http://www.w3.org/XQueryTest/testcases"
xmlns:tc="http://www.w3.org/XQueryTest/testcases">
  <element name="root">
    <complexType>
      <sequence>
        <element ref="tc:schema-element-head"/>
      </sequence>
    </complexType>
  </element>
  <element name="schema-element-head" type="string"/>
  <element name="schema-element-group" type="string"
substitutionGroup="tc:schema-element-head"/>
</schema>

And $input-context bound to the document:

<tc:root xmlns:tc="http://www.w3.org/XQueryTest/testcases">
  <tc:schema-element-group>string</tc:schema-element-group>
</tc:root>

And the query

import schema namespace tc="http://www.w3.org/XQUeryTest/testcases";
declare variable $input-context1 as document-node(schema-element(tc:root))
external;
$input-context/tc:root/tc:schema-element-group

Clearly the expected result should be the schema-element-group element, but I
think the typing rules give the type of the axis expression as empty-sequence.

$input-context has type: document ( element tc:root of Type )
where Type is element tc:element-schema-head of xsd:string

Firstly I don't no believe any of the judgements (particularly the with union
interpretation judgement) cause tc:element-schema-group to be included in Type

Hence we ended up wanting to make the judgement from 8.2.3.1.1

statEnv |- test tc:schema-element-group with element of element
tc:schema-element-head of xsd:string : element tc:schema-element-group of
xsd:string

In the recommendation I don't think this case is caught, as clearly the QNames
schema-element-group and schema-element-head don't match. But I don't think it
is caught by the "Lastly, if none of the above rules holds, then the type of
the input expression is empty." as the line:

statEnv |-  not(element ElementNameOrWildcard 1 TypeSpecifier1 <: element
ElementNameOrWildcard 2 TypeSpecifier2)

is false as I believe

element tc:schema-element-group <: element tc:schema-element-head

is true, as subtyping (<:) is true if every value which "matches" the first
type also "matches" the second, and the "matches" judgement uses judgements
"name lookup" and hence "substitutes for".

I think this problem was noted in #4261, and fixed in the erratum. And I now
agree the final empty-sequence case covers what is not covered in the prior
cases, particularly with rule 13, but I'm am unsure if it is fixed in the
correct way, as now it would cause the above query to statically type to the
empty-sequence. Should the change not be one using subtyping rather than name
matching for the prior static judgements?

Received on Thursday, 14 February 2008 12:19:58 UTC