- From: Robert Sanderson <azaroth42@gmail.com>
- Date: Mon, 9 May 2016 09:37:23 -0700
- To: spec-prod <spec-prod@w3.org>
- Cc: Chairs <chairs@w3.org>, Tobie Langel <tobie.langel@gmail.com>, Marcos Caceres <w3c@marcosc.com>, "Tab Atkins Jr." <jackalmage@gmail.com>, Shane McCarron <shane@spec-ops.io>, Denis Ah-Kang <denis@w3.org>, Antonio Olmo Titos <antonio@w3.org>
- Message-ID: <CABevsUF-DgP_QzUuJqHExrR_+3GUQGPbdMQZpEQN7Tnxdh0YBA@mail.gmail.com>
Dear Philippe, all,
In the Web Annotation model we also refer to W3C specifications' URIs as a
means of identifying the URI fragment rules that they maintain.
For example, we currently recommend the URI "
http://www.w3.org/TR/media-frags/" as a way to say "this fragment conforms
to the rules of the media fragments specification".
You can see the table here:
https://www.w3.org/TR/annotation-model/#fragment-selector
I believe that this would also fall under the change to use https rather
than http URIs, correct?
As we intend to go to CR in the next few weeks, would the recommendation be
to change to https now in advance?
Many thanks,
Rob Sanderson
On Mon, May 9, 2016 at 9:19 AM, Philippe Le Hegaret <plh@w3.org> wrote:
> Chairs, Editors,
> Tool makers,
>
> we had requests to use https in the /TR documents for quite sometime now
> so here is a proposal.
>
> Timeline:
>
> The current target for deployment is July 1st, to give enough time for
> folks to comment and tools to adapt.
>
> We'd appreciate comments on the new rule and the metadata/API before June
> 15, 2016.
>
> You may use issue #282 in Echidna to provide feedback:
> https://github.com/w3c/echidna/issues/282
>
> Proposed new rule:
>
> [[
> All links to www.w3.org that are
> required by the publication requirements MUST start with
> https://www.w3.org/, with the exception of namespace URIs.
> ]]
>
> Here is the exact list of links impacted by the changes:
>
> This impacts:
> - link to TR stylesheets
> - links to W3C logo and W3C main homepage
> - ALL document identifiers ("This Version", "Latest Version", "Previous
> Version", etc.)
> - links to W3C IPR notice, liability, trademark, and document use
> - link to the W3C technical reports index
> - links to W3C Patent Policy, patent disclosures, and W3C Process
> - link to fixup.js and other supported scripts
> - links to errata page and translation
>
> The Namespace URI policy [1] is NOT impacted by this change.
>
> All other links to www.w3.org or other domains are NOT impacted by the
> change, including normative and informative references. We do however
> recommend to use https whenever possible.
>
> Depending on your type of documents, this impacts around 16 links maximum.
>
> The rational for the move goes as follows:
>
> 1. Our canonical URI is https (well, as much as possible)
> https://www.w3.org/2016/04/07-hsts-uir/
> 2. Using relative paths break drafts that are hosted outside our website,
> e.g. w3c.github.io
> 3. Using protocol relative links would make it a more complex rule given
> that links like "This Version" are displayed to the user.
>
>
> Impact on metadata and API:
>
> (unless you're a tool user or maker, feel free to ignore anything below)
>
>
>
> Let's imagine that HTML 5.1 gets published in June, July and August 2016
> and that we do the switch for the new rule on July 1, 2016. The proposal is
> to obtain the following:
>
>
> HTML document published in /TR
>
> June 2016 document:
>
> This version:
> http://www.w3.org/TR/2016/WD-html51-20160602/
> Previous Version:
> http://www.w3.org/TR/2016/WD-html51-20160502/
> Latest version:
> http://www.w3.org/TR/html51/
>
> July 2016 document:
>
> This version:
> https://www.w3.org/TR/2016/WD-html51-20160717/
> Previous version:
> https://www.w3.org/TR/2016/WD-html51-20160602/ (or http://...)
> Latest version:
> https://www.w3.org/TR/html51/
>
> August 2016 document:
>
> This version:
> https://www.w3.org/TR/2016/WD-html51-20160817/
> Previous Version:
> https://www.w3.org/TR/2016/WD-html51-20160717/
> Latest version:
> https://www.w3.org/TR/html51/
>
> tr.rdf representation of those documents:
>
> (note that this change may break specref.org @@check with Tobie)
>
> <!-- W3C server redirects from http to https, so let's represent this
> equivalence here -->
> <rdf:Description rdf:about="http://www.w3.org/TR/html51/">
> <sameWorkAs rdf:resource="https://www.w3.org/TR/html51/"/>
> </rdf:Description>
>
> <WD rdf:about="http://www.w3.org/TR/2016/WD-html51-20160602/">
> <dc:date>2017-06-02</dc:date>
> <dc:title>HTML 5.1</dc:title>
> <doc:obsoletes
> rdf:resource="http://www.w3.org/TR/2016/WD-html51-20160502/"/>
> <doc:versionOf rdf:resource="http://www.w3.org/TR/html51/"/>
> <patentRules
> rdf:resource="https://www.w3.org/Consortium/Patent-Policy-20040205/"/>
> </WD>
>
> <WD rdf:about="https://www.w3.org/TR/2016/WD-html51-20160717/">
> <dc:date>2017-07-17</dc:date>
> <dc:title>HTML 5.1</dc:title>
> <!-- we force http:// for all *dated* URI published before the
> switch -->
> <doc:obsoletes
> rdf:resource="http://www.w3.org/TR/2016/WD-html51-20160602/"/>
> <doc:versionOf rdf:resource="https://www.w3.org/TR/html51/"/>
> <patentRules
> rdf:resource="https://www.w3.org/Consortium/Patent-Policy-20040205/"/>
> </WD>
>
> <WD rdf:about="https://www.w3.org/TR/2016/WD-html51-20160817/">
> <dc:date>2017-08-17</dc:date>
> <dc:title>HTML 5.1</dc:title>
> <doc:obsoletes
> rdf:resource="https://www.w3.org/TR/2016/WD-html51-20160717/"/>
> <doc:versionOf rdf:resource="https://www.w3.org/TR/html51/"/>
> <patentRules
> rdf:resource="http://www.w3.org/Consortium/Patent-Policy-20040205/"/>
> </WD>
>
> w3c api:
>
> Before the switch:
>
> "_embedded": {
> "version-history": [
> {
> "status": "Working Draft",
> "uri":
> "http:\/\/www.w3.org\/TR\/2016\/WD-html51-20160602\/",
> "date": "2016-06-02",
> "informative": false,
> "title": "HTML 5.1",
> "shortlink": "http:\/\/www.w3.org\/TR\/html51\/",
> "editor-draft": "https:\/\/w3c.github.io\/html\/",
> "process-rules":
> "http:\/\/www.w3.org\/2015\/Process-20150901\/",
> }, ... ]
>
> After the switch: we can't represent the equivalence between
> http://www.w3.org/TR/html51/ and https://www.w3.org/TR/html51/ so we
> make the choice of using https. This could break things but the API
> isn't largely used yet so we might get away with it. Most critical would
> be that we might break pheme (and consequently ash-nazg...).
>
> "_embedded": {
> "version-history": [
> {
> "status": "Working Draft",
> "uri":
> "http:\/\/www.w3.org\/TR\/2016\/WD-html51-20160602\/",
> "date": "2016-06-02",
> "title": "HTML 5.1",
> "shortlink": "https:\/\/www.w3.org\/TR\/html51\/",
> "process-rules":
> "https:\/\/www.w3.org\/2015\/Process-20150901\/",
> },
> {
> "status": "Working Draft",
> "uri":
> "https:\/\/www.w3.org\/TR\/2016\/WD-html51-20160717\/",
> "date": "2016-07-17",
> "title": "HTML 5.1",
> "shortlink": "https:\/\/www.w3.org\/TR\/html51\/",
> "process-rules":
> "https:\/\/www.w3.org\/2015\/Process-20150901\/",
> },
> {
> "status": "Working Draft",
> "uri":
> "https:\/\/www.w3.org\/TR\/2016\/WD-html51-20160817\/",
> "date": "2016-08-17",
> "title": "HTML 5.1",
> "shortlink": "https:\/\/www.w3.org\/TR\/html51\/",
> "process-rules":
> "https:\/\/www.w3.org\/2015\/Process-20150901\/",
> }, ... ]
>
>
> Thank you,
>
> Philippe
>
> [1] https://www.w3.org/2005/07/13-nsuri
>
>
--
Rob Sanderson
Semantic Architect
The Getty Trust
Los Angeles, CA 90049
Received on Monday, 9 May 2016 16:44:46 UTC