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 30003 - [XSLT30]Spec links to https://www.w3.org/2012/07/schema-for-xslt30.rnc but I get a "The document name you requested (/2012/07/schema-for-xslt30.rnc) could not be found on this server"
Summary: [XSLT30]Spec links to https://www.w3.org/2012/07/schema-for-xslt30.rnc but I ...
Status: RESOLVED INVALID
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XSLT 3.0 (show other bugs)
Version: Candidate Recommendation
Hardware: PC Windows NT
: P2 editorial
Target Milestone: ---
Assignee: Michael Kay
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-11-13 11:36 UTC by Martin Honnen
Modified: 2016-11-16 17:03 UTC (History)
0 users

See Also:

Attachments

Description Martin Honnen 2016-11-13 11:36:41 UTC 
The current spec links to https://www.w3.org/2012/07/schema-for-xslt30.rnc as the RNC schema for XSLT 3.0 but when I follow that link (tried with Firefox, Edge and Chrome) the server displays 

----------------------------------------------------
Multiple Choices

The document name you requested (/2012/07/schema-for-xslt30.rnc) could not be found on this server. However, we found documents with names similar to the one you requested.
Available documents:

/2012/07/schema-for-xslt30.xsd (common basename)
-----------------------------------------------------



I am not sure whether that is a server misconfiguration or an incorrect link.
Comment 1 Michael Kay 2016-11-13 15:13:13 UTC 
This seems to be an unintended side-effect of making our internal editors' drafts public. When an internal draft points to a document in W3C yyyy/mm space, it indicates an intent that the target document will be there at the time of publication (or quite possibly in some other location based on the actual date of publication. These links will be resolved when we issue a public (or perhaps I should say "formal public") draft, but they are not expected to be correct each time we upload a new internal increment.
Comment 2 Martin Honnen 2016-11-13 15:49:10 UTC 
(In reply to Michael Kay from comment #1)
> These links will be resolved when we issue a
> public (or perhaps I should say "formal public") draft, but they are not
> expected to be correct each time we upload a new internal increment.

I see, in that case this bug can be closed I guess.