This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Catalog003 checks to see that all error test cases have at least one expected error. This does not appear to be the case for K2-SeqExprCast-421. I believe that the scenario for this test case should be changed to standard.
Should be fixed in CVS.
This test (K2-SeqExprCast-421) was previously catalogued as expecting error FORG0001. It's not clear to me why it has changed. The test is xs:anyURI("foo://") and it seems to me that "foo://" is indeed an invalid URI: RFC3986 states: When authority is not present, the path cannot begin with two slash characters ("//") The rule is less clearly expressed in RFC2396 (which is what Schema Part 2 actually references) but I think it's still there.
Ok, then http://www.w3.org/Bugs/Public/show_bug.cgi?id=5695 was resolved incorrectly. I changed back to the former.
Sorry, I think foo:// is valid. Quoting the specification: hier-part = "//" authority path-abempty / path-absolute / path-rootless / path-empty The scheme and path components are required, though the path may be empty (no characters). When authority is present, the path must either be empty or begin with a slash ("/") character. When authority is not present, the path cannot begin with two slash characters ("//"). These restrictions result in five different ABNF rules for a path (Section 3.3), only one of which will match any given URI reference. The following are two example URIs and their component parts: foo://example.com:8042/over/there?name=ferret#nose \_/ \______________/\_________/ \_________/ \__/ | | | | | scheme authority path query fragment | _____________________|__ / \ / \ urn:example:animal:ferret:nose So this is saying that: path-absolute path-rootless path-empty may not begin with '//'. path-abempty can begin with '//' even if the authority is the empty string - because the authority is still present. Note that the empty string is a valid authority (matching the 'reg-name' production). So foo:// is a valid URI with an empty authority and empty path. The '//' here is _not_ part of the path. Here's what Microsoft's .NET System.Uri class does with this... $ New-object Uri('foo://') AbsolutePath : / AbsoluteUri : foo:/// Authority : Host : HostNameType : Basic IsDefaultPort : True IsFile : False IsLoopback : True IsUnc : False LocalPath : / PathAndQuery : / Port : -1 Query : Fragment : Scheme : foo OriginalString : foo:// DnsSafeHost : IsAbsoluteUri : True Segments : {/} UserEscaped : False UserInfo :
And this is what Java 5 (class java.net.URI) has to say about it: new URI("foo://") Exception in thread "main" java.net.URISyntaxException: Expected authority at index 6: foo:// These RFCs are a mess: intelligent implementors can interpret the phrase "when authority is present" in different ways. We're not trying to test URI class libraries, we should stick to cases that are uncontroversial.
Interesting! Where can one get clarification on an RFC?
I agree, the test in CVS now accepts pretty much anything.
Splendid! That'll kepp everyone happy :)