W3C home > Mailing lists > Public > www-tag@w3.org > June 2014

Re: W3C URN scheme 'root' doesn't exist?

From: Robin Berjon <robin@w3.org>
Date: Mon, 23 Jun 2014 21:08:02 +0200
Message-ID: <53A87B12.10101@w3.org>
To: David Singer <singer@apple.com>, "Henry S. Thompson" <ht@inf.ed.ac.uk>
CC: Silvia Pfieffer <silviapfeiffer1@gmail.com>, TAG List <www-tag@w3.org>
On 23/06/2014 19:09 , David Singer wrote:
> On Jun 23, 2014, at 10:06 , Henry S. Thompson <ht@inf.ed.ac.uk>
> wrote:
>> David Singer writes:
>>> Since we want permanent labels, I fear that tying them to a
>>> version of the spec and its anchors and/or sections, and
>>> location, might be fragile.  And, as Robin points out, we don’t
>>> need choice.
>>
>> The whole point of W3C's usage of undated URIs is so that the
>> location _doesn't_ change.  As long as there is a W3C,
>> http://www.w3.org/TR/html5/#attr-trace-kind-subtitles will
>> resolve. That's as good a promise as you're going to get
>> (persistence as commonly understood is a service-level guarantee,
>> _not_ a property of names!).
>
> and when HTML5 moves to HTML6 or 7?  Is the name really specific to
> this version of HTML?

That's why I suggested using /html/ instead of /html5/ if you want 
something that updates with versions. If you want something that's 
guaranteed to be absolutely stable forever, use the dated version as 
Henry suggests (or a namespace document).

> what if some editor decides to change the name of the anchor
> (consistently in the document), so now it’s
>
> http://www.w3.org/TR/html5/#attribute-trace-kind-subtitles
>
> is there really a guarantee of stability for anchor names?

That's undocumented, so if you need it to resolve (I thought you just 
needed names) then you shouldn't rely on it — we've broken these several 
times before. In practice we probably won't break this for /html5/; we 
will almost certainly break them in some future version.

-- 
Robin Berjon - http://berjon.com/ - @robinberjon
Received on Monday, 23 June 2014 19:08:15 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:57:02 UTC