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

I would actually prefer that ‘the w3c’ simply decide, I think.  Ideally there is a sentence somewhere saying roughly

“The URI to identify an HTML[5] track ‘kind’ value, when used in other contexts, is http://…”

As I say, DASH uses a Scheme (think, namespace) + Value pair.

On Jun 23, 2014, at 12:08 , Robin Berjon <robin@w3.org> wrote:

> 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

David Singer
Manager, Software Standards, Apple Inc.

Received on Monday, 23 June 2014 21:22:14 UTC