30003 2016-11-13 11:36:41 +0000 [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" 2016-11-16 17:03:39 +0000 1 1 1 Unclassified XPath / XQuery / XSLT XSLT 3.0 Candidate Recommendation PC Windows NT RESOLVED INVALID P2 editorial --- 1 martin.honnen mike public-qt-comments oldest_to_newest 128164 0 martin.honnen 2016-11-13 11:36:41 +0000 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. 128165 1 mike 2016-11-13 15:13:13 +0000 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. 128166 2 martin.honnen 2016-11-13 15:49:10 +0000 (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.