This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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?
The Product/Component of this issue is "XML Query Test Suite". Did you mean to raise it against the Formal Semantics?
Sorry. Yes, it should be formal semantics. Will change.
(In reply to comment #0) > $input-context has type: document ( element tc:root of Type ) > where Type is element tc:element-schema-head of xsd:string That's not what I get. FS 5.14 Variable Declaration / Static Context Processing / rule 3 tells us that the type of $input-context is [[ document-node(schema-element(tc:root)) ]]_sequencetype FS 3.5.4 SequenceType Matching / Normalization / rule 19 maps that to: document { [[ schema-element(tc:root) ]]_sequencetype & (pi|comment)* } which rule 11 maps to: document { element tc:root & (pi|comment)* } ---- Moreover, when I try to work through the (normalization and) static analysis of $input-context/tc:root/tc:schema-element-group I don't get as far as you -- I can't figure out the Definition that would be put in elemDecl for <element name="root">...</element>. I can see that D.4.1 Global element declarations / Schema mapping / rule 2 maps it to define element tc:root [[ <complexType>...</complexType> ]]_content(tc) and D.5.2 Local complex type / Schema mapping / rule 1 maps that to define element tc:root [[ <sequence>...</sequence> ]]_mixed_content(tc) but I don't get any farther than that.
I agree with your first point, but I think the (pi|comment)* will soon disappear when we start applying the axis tests. As for the rest of the expansion of element tc:root. I think D.9.3 will expand the <sequence> element for us: define element tc:root [ (<element ref="tc:schema-element-head"/>) ]_mixed_content(tc) Then D.4.2 will handle the <element ref="tc:schema-element-head"/>: define element tc:root [ (element tc:schema-element-head) ]_mixed_content(tc) which will then be defined by D.4.1: define element tc:root [ (element tc:schema-element-head of type xsd:string) ]_mixed_context(tc) Or have I misunderstood something?
(In reply to comment #4) > > As for the rest of the expansion of element tc:root. > > I think D.9.3 will expand the <sequence> element for us: D.9.3 (sub-)defines the []_content mapping, not the []_mixed_content mapping.
OK. Presumably we should be have some rules to work out a type for <complexType><sequence>...</sequence></complexType> though? Can the current D.9.3 rule ever be hit? I think we can only get a <sequence> within a <complexType>, so should the content type mapping match? i.e. be _mixed_content instead of _content.
I believe this issue gets into problems with Appendix D that would be difficult to fix within the timeframe of FS 1.0. Therefore, I am marking the issue as resolved-LATER, and hope to fix it in FS 1.1. If you accept this resolution, please mark the issue CLOSED.
After 3 months with no response from the original reporter, I am marking this issue CLOSED. Feel free to reopen it if you disagree with this outcome.