[Playlist] Question on identifier content, URI and URN

[Lucas Gonze]

I can see that such a basic problem seems amazing, so let me explain the 
application-level benefit we were trying to achieve.  Hopefully this 
will make the mess more justified, if not actually excused.

We were concerned with enabling the http scheme to be used purely for 
identifiers.  Let's say, for example, that there could be an identifier 
"http://example.com/acdc/girlsgotrhythm" which was used to signify a 
specific song, regardless of the address of any particular instance of 
the song.  This identifier would be a mapping to the song at a semantic 
level only, so that a different rip with different settings would still 
match the same underlying composition and sound recording.  It might 
still return something when dereferenced, like a set of metadata about 
the song or an explanation of how it might be used, it just wouldn't be 
dereferenceable to obtain a representation of the song.

For an example of such a URL in the real world, see 
http://musicbrainz.org/track/7e1d6f5f-0ac3-4889-8b57-506a67b459fc.html .

In the olden days there were specific schemes designed for use this way. 
   The urn scheme, for one.  :)  That has changed.  In recent times many 
people have stopped thinking of the http scheme as being restricted to 
locators; hence our need to distinguish at the XSPF level between an 
http URI used as an identifier and an http URI used as a locator.

You can think of the whole mess this way: the identifier element is a 
hook for metadata curators like Musicbrainz and Gracenote.

Ok, on to details.

Sebastian Pipping wrote:
> ----------------------------------------------------------------
> So in XSPF a URN is everything starting with "<scheme>:"?
> All URLs are URNs? All URIs are URNs?

All URNs are URIs but all URIs are not URNs.  A URN is a URI which is 
not necessarily resolvable.

> Please point me to the right grammars so I can be sure to
> implement the right thing for isURN() and isURL().

Do isURI() rather than either of those.  The distinction between a name 
and a locator doesn't have any meaning at the parser level.

Lucas said:
>>I don't believe that I could do this
>> many edits without creating what is essentially a new version, and there
>> aren't resources for doing a new version.

Sebastien replied:
> Which edits do you mean exactly? I don't understand.

I mean the edits it would take to put things right.

Sebastien said:
> There are several places where the URL/URN migration of
> XSPF-1 was not finished (where it still reads "URI").
> Here is my summary:
> 
> * URN - 4.1.1.2.11.1.1 - playlist.link[@rel]
> * URN - 4.1.1.2.12.1.1 - playlist.meta[@rel]
> * URL - 4.1.1.2.13.1.1 - playlist.extension[@application]
> * URL - 4.1.1.2.14.1.1.1.13.1.1 - track.playlist.extension[@application]
> * URL - 6.3 Extension URIs
> * URL/URN - All testcases that match *-noturi-*.xspf

Thank you!  I am very grateful that you have given the spec such a 
careful proofreading.  This is not a specious comment, it is great to 
get such detailed comments on the spec language, which has many drafting 
problems that nobody has taken the trouble to list.

I went through each of the items you have identified and found that the 
  reasoning which I will articulate below applied to all of them.  In 
every case the item was defined in one location as a URN and in another 
as a URI.

It is never inaccurate to call a URN a URI.   Quoting Wikipedia[1], "the 
terms URL and URN are context-dependent aspects of URIs, and rarely need 
to be distinguished."

I'm not arguing that the situation is good, by the way.  I think that 
the problem is not inconsistent use of URI vs URN so much as the use of 
the terms URN and URL at all.  This is confusing, but I don't believe 
that the problem by itself rises to the level of something which would 
justify either modifying the ratified spec in-place or chartering a new 
group to write a new spec.


thanks.

-Lucas

[1] http://en.wikipedia.org/wiki/Uniform_Resource_Identifier