Neil Van Dyke wrote:
> Alex Shinn <xxxxxx@gmail.com> wrote at 2006-01-26T10:37:02+0900:
...
>>The recommended approach would probably be to use a URN (rfc2141):
>
>
> That's what I would've said, til I heard an offhand remark from one
> person a while ago, which made me wonder whether URNs had fallen into
> disfavour.  I've not been in the loop on that lately.  I definitely
> think that some W3C and IETF people should be consulted about the use of
> URIs in the Scheme module system, if they've not been already.

That person may have been thinking of the issues described in RFC 3305
(URIs, URLs, and URNs), which are summarized nicely in its section 2.

Summarizing further, URNs are no longer considered to be a disjoint
subspace of the entire URI space: a particular URI scheme can define its
own subspaces, which could include both URN and URLs.

If the "scheme:" URI scheme were registered (assuming no objections to a
scheme named "scheme"), then it could be used for both URNs and URLs, if
necessary.

OTOH, the "urn:" URI scheme is intended only for URNs, i.e. names that
are not intended to be treated as explicit location specifiers.  That
would give URIs like "urn:scheme:r6rs" and "urn:scheme:srfi-N" (slashes
are disallowed in URNs, according to RFC 2141).

The other library URIs could also be modified for URN syntax.  One of
the examples in the SRFI could become:

   urn:scheme:acme.com:wiley:quicksort

This doesn't necessarily preclude using other kinds of URIs to identify
libraries.

Of course, the "urn:scheme:" part could be assumed where appropriate,
leaving only the essential bits.  E.g. (acme.com wiley quicksort) could
be a library specifier which maps to the above URN, which in turn maps
to an actual resource.

The above is just laying out some possibilities w.r.t. URNs.  I'm not
advocating anything, and I'm not one of the authors of this SRFI.

Anton