- From: <bugzilla@jessica.w3.org>
- Date: Tue, 03 Jan 2017 17:37:44 +0000
- To: public-qt-comments@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=30039 Bug ID: 30039 Summary: Schema substitution.xsd depends on XSD 1.0 Product: XPath / XQuery / XSLT Version: Candidate Recommendation Hardware: PC OS: All Status: NEW Severity: normal Priority: P2 Component: XQuery 3 & XPath 3 Test Suite Assignee: oneil@saxonica.com Reporter: mike@saxonica.com QA Contact: public-qt-comments@w3.org Target Milestone: --- I believe that the schema substitution.xsd used with QT3 test set prod-SchemaImport is OK in XSD 1.0 but not in XSD 1.1 (But I would appreciate someone else checking my reasoning...) The schema declares a complex type that blocks extension: <xs:complexType name="Ht" block="extension"> and a type that extends it: <xs:complexType name="HtE"> <xs:complexContent> <xs:extension base="s:Ht"> It defines an element declaration: <xs:element name="H" type="s:Ht" nillable="true"/> and a substitution group member: <xs:element name="G" substitutionGroup="s:H" type="s:HtE"/> So in the component model, Ht has {prohibited substitutions} = (extension), and in consequence HtE is not *validly derived* from Ht. Rule 4 of 3.3.6.1 Element Declaration Properties correct requires: For each member M of E.{substitution group affiliations}, E.{type definition} is ·validly substitutable· for M.{type definition}, subject to the blocking keywords in M.{substitution group exclusions}. Because HtE is not validly derived from Ht, the type of G is not validly substitutable for the type of H. But H is a member of G.{substitution group affiliations} ("A set of the element declarations ·resolved· to by the items in the ·actual value· of the substitutionGroup [attribute]"), therefor Element Declaration Properties is not satisfied, and therefore we do not have a valid schema. In XSD 1.0 the situation is subtly different. Rule 4 of Element Declaration Properties Correct now reads: If there is a {substitution group affiliation}, the {type definition} of the element declaration must be validly derived from the {type definition} of the {substitution group affiliation}, given the value of the {substitution group exclusions} of the {substitution group affiliation}, as defined in Type Derivation OK (Complex) (§3.4.6) One change here is that in XSD 1.0 an element can belong to only one substitition group. The other change is the use phrase "validly derived" rather than "validly substitutable". Type D is not validly derived from type B given blocking keywords K if K includes "extension" and B blocks extension. But in the XSD 1.0 formulation, the phrase "validly derived" is not qualified by "given K=(extension)" - K is determined solely by what the substitution group blocks, not by what the type blocks. Essentially, this schema is valid in XSD 1.0 only because of a loophole in the XSD 1.0 specification that was plugged in XSD 1.1. -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Tuesday, 3 January 2017 17:37:52 UTC