30180 2017-09-11 15:32:58 +0000 [xslt30ts] Test case error-0905a - invalid xs:anyURI 2017-09-12 23:29:17 +0000 1 1 1 Unclassified XPath / XQuery / XSLT XSLT 3.0 Test Suite Proposed Recommendation PC All RESOLVED FIXED P2 normal --- 1 mike abel.online abel.braaksma public-qt-comments oldest_to_newest 128886 0 mike 2017-09-11 15:32:58 +0000 Test case error-0905a expects error XTDE0905: [ERR XTDE0905] It is a dynamic error if the string value of the new namespace node is not valid in the lexical space of the datatype xs:anyURI, or if it is the string http://www.w3.org/2000/xmlns/. The value in question is "####". XSD 1.1 states: The value space of anyURI is the set of finite-length sequences of zero or more characters (as defined in [XML]) that ·match· the Char production from [XML]. This is therefore a valid xs:anyURI according to XSD 1.1, therefore no error should be generated if XSD 1.1 is supported. 128887 1 mike 2017-09-11 15:39:43 +0000 Created variants of the test for XSD 1.0 and XSD 1.1. 128890 2 abel.braaksma 2017-09-12 17:39:23 +0000 Interestingly, in FO31 the spec writes: « For xs:anyURI, the extent to which an implementation validates the lexical form of xs:anyURI is ·implementation-dependent·.» Not sure if the difference was intentional. FO31 is more lenient than XSD11, it doesn't mention the XML Char limitation. Perhaps we should add for XTDE0905 that raising this error is implementation dependent, unless it is "http://www.w3.org/2000/xmlns/". I also found that in 5.8 we say about Uri References: « [Definition: Within this specification, the term URI Reference, unless otherwise stated, refers to a string in the lexical space of the xs:anyURI datatype as defined in [XML Schema Part 2].] Note that this is a wider definition than that in [RFC3986]» which doesn't seem to mention XSD 1.1, nor the leniency of xs:anyURI validation in FO31. If we could, I would prefer that we follow FO31 in making any and all URI References and xs:anyURI mentions implementation-dependent with respect to validation of the validity of the URI (per RFC or per XSD). 128891 3 abel.braaksma 2017-09-12 17:42:51 +0000 > [FO31] doesn't mention the XML Char limitation. This could only mean that corner cases like xs:anyURI('') or xs:anyURI('&#xD800') would be legal in FO31 and illegal in XSD11. When XSLT or XPath is used from within XML 1.0, that wouldn't be possible anyway. 128892 4 mike 2017-09-12 18:52:13 +0000 >FO31 is more lenient than XSD11, it doesn't mention the XML Char limitation. It doesn't need to. The section you cite from (§19.2) is about casting from xs:string, and all characters in an xs:string instance are legal XML Char's by definition. >« [Definition: Within this specification, the term URI Reference, unless otherwise stated, refers to a string in the lexical space of the xs:anyURI datatype as defined in [XML Schema Part 2].] I don't think it needs to because we have a blanket statement that processors can choose which XSD version to support. But in any case, the definition of "URI Reference" has no bearing on this bug. The spec issues concerning the precise rules for namespace URIs are one of those areas that the WG has spent a lot of time on, and spending even more time is unlikely to sort out the mess, because the mess is inherited from other specs. So I don't suggest we attempt it. I'm just trying to fix the test case, which I think fairly clearly depends on which XSD version you're using. 128893 5 abel.braaksma 2017-09-12 23:29:17 +0000 (In reply to Michael Kay from comment #4) > The spec issues concerning the precise rules for namespace URIs are one of > those areas that the WG has spent a lot of time on, and spending even more time > is unlikely to sort out the mess, because the mess is inherited from other specs Makes sense to me. (In reply to Michael Kay from comment #4) > I'm just trying to fix the test case, which I think fairly clearly depends on > which XSD version you're using. Yes, after reading your answer, I wholeheartedly agree. And I forgot about our "blanket statement" on the supported XSD version. Let's keep this resolved ;).