This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 30180 - [xslt30ts] Test case error-0905a - invalid xs:anyURI
Summary: [xslt30ts] Test case error-0905a - invalid xs:anyURI
Status: RESOLVED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XSLT 3.0 Test Suite (show other bugs)
Version: Proposed Recommendation
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Abel Braaksma
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-09-11 15:32 UTC by Michael Kay
Modified: 2017-09-12 23:29 UTC (History)
1 user (show)

See Also:


Attachments

Description Michael Kay 2017-09-11 15:32:58 UTC
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.
Comment 1 Michael Kay 2017-09-11 15:39:43 UTC
Created variants of the test for XSD 1.0 and XSD 1.1.
Comment 2 Abel Braaksma 2017-09-12 17:39:23 UTC
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).
Comment 3 Abel Braaksma 2017-09-12 17:42:51 UTC
> [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.
Comment 4 Michael Kay 2017-09-12 18:52:13 UTC
>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.
Comment 5 Abel Braaksma 2017-09-12 23:29:17 UTC
(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 ;).