30141 2017-07-10 15:27:56 +0000 [xslt30] Schema for XSLT 3.0 describes xsl:accept/@names and xsl:expose/@names incorrectly 2018-01-03 00:11:52 +0000 1 1 1 Unclassified XPath / XQuery / XSLT XSLT 3.0 Proposed Recommendation PC All RESOLVED FIXED P2 normal --- 1 mike mike martin.honnen public-qt-comments oldest_to_newest 128689 0 mike 2017-07-10 15:27:56 +0000 Resolution of test case bug 30140 reveals that xsl:accept/@names and xsl:expose/@names are described in schema-for-stylesheet-documents to have type xsl:EQNames. This type does not allow wildcard tokens such as "*", "p"*", or "*:local", which the normative prose clearly allows. As far as I can see the bug is not present in the Relax NG version of the schema, which uses the type "tokens" for these attributes. 128690 1 mike 2017-07-10 15:33:05 +0000 Changing the type of these attributes from xs:EQNames to xs:nametests is probably sufficient to fix the problem. I am provisionally applying this change in the version of the schema that appears in the test suite test-set named "catalog". 128691 2 mike 2017-07-10 15:45:41 +0000 Unfortunately this reveals another error: the definition of type xsl:nametests does not permit the value "Q{uri}*" which is allowed in existing attributes of type xsl:nametests as well as these new uses. Again, I've fixed this in the test suite version of the schema. 128692 3 mike 2017-07-10 15:49:22 +0000 The schema also fails to permit the attribute xsl:mode/@_use-accumulators. 128694 4 mike 2017-07-10 16:06:41 +0000 The schema includes an assertion for xsl:function elements: <xs:assert test="every $e in xsl:param satisfies empty($e/(@required | @_required))"> <xs:annotation> <xs:documentation> <p>A parameter for a function must have no <code>required</code> attribute.</p> </xs:documentation> </xs:annotation> </xs:assert> This disagrees with §9.2 which states that the attribute @required is permitted provided it has the value yes|true|1. 128695 5 mike 2017-07-10 16:11:41 +0000 The definition of xsl:function allows attribute _identity-sensitive in place of _new-each-time. 128697 6 mike 2017-07-10 16:29:15 +0000 The definition of xsl:nametests also does not allow tokens such as f:foo#2 - which are allowed on xsl:accept/@names and xsl:expose/@names, but not on xsl:strip-space/elements, making this a different data type. 128699 7 mike 2017-07-10 21:33:52 +0000 I've now made changes to the version of the schema in the test suite such that all correct schemas now validate. Had to make a few further adjustments to the catalog-005 test: * Don't attempt to validate stylesheets with literal result elements in the fn namespace (they won't be valid if the schema for the fn namespace is known) * Exclude stylesheets with //@xsl:version > 3.0 (forwards compatibility mode - everything is allowed) 128700 8 mike 2017-07-10 21:35:44 +0000 One other problem was fixed: The simple type "method" does not allow the values "json" or "adaptive". 128930 9 mike 2017-10-13 20:21:28 +0000 Erratum E10 has been drafted. We need to work out how best to publish a corrected schema. 128948 10 mike 2017-10-29 23:13:15 +0000 The changes were accepted. We discussed the process issues of how to republish a revised schema. In the short term, the version of the schema published at https://www.w3.org/TR/xslt-30/schema-for-xslt30.xsd (which is linked from the spec) will remain unchanged, and the corrected schema will be published in errata space at http://www.w3.org/XML/2017/qt-errata/schema-for-xslt30.xsd which will be linked from the errata document. ---- There is another minor issue with the schema that should be fixed. In the simple type "nametest" we allow the options prefix:* and *:local using the patterns <xs:pattern value="\i\c*:\*"/> <xs:pattern value="\*:\i\c*"/> However, the character classes \i and \c both allow a colon (they correspond to NamestartChar and NameChar in the XML recommendation), so this definition is excessively liberal. They should be replaced by [\i-[:]] and [\c-[:]] respectively. I have fixed this, but leaving the bug open for another round of WG review. 128965 11 mike 2017-11-09 17:22:29 +0000 Resolution accepted by the WG 129042 12 mike 2018-01-03 00:11:52 +0000 *** Bug 30215 has been marked as a duplicate of this bug. ***