W3C home > Mailing lists > Public > uri@w3.org > October 2003

RE: uri, urn and info

From: Hammond, Tony (ELSLON) <T.Hammond@elsevier.com>
Date: Sat, 11 Oct 2003 09:24:08 +0100
Message-ID: <54A600C436EA694581B93E4BD4D4788A06B73CA0@elslonexc004.eslo.co.uk>
To: 'John Cowan' <jcowan@reutershealth.com>
Cc: 'Larry Masinter' <LMM@acm.org>, uri@w3.org

> > There is no requirement that URN namespaces have 'persistence of
> > identifiers as a primary purpose'.
> The above statement conflicts with this opening passage from RFC 2141:
> 	"Uniform Resource Names (URNs) are intended to serve as persistent,
> location-independent, resource identifiers."
> So, again we are left feeling really confused. Maybe it's just the words
> that are being used. 

John Cowan writes: 

  Construe, construe!  There is no requirement that URN namespaces have
  persistence of identifiers AS THEIR PRIMARY PURPOSE.  urn:newsml:
  for example, are primarily intended for location independence and
  persistence may or may not be important (notoriously, yesterday's
  wraps today's fish).

I thought I was construing correctly. I read primary as meaning "first". I
follow the word order as presented in the RFC. I understand "intend" to have
its normal intent.

All you have demonstrated to me is that the "newsml" URN NID may have been
inappropriately allocated. I therefore query what the true intent of the
"urn" URI scheme is for. It could seem to be providing a miscellaneous
category for URI allocation.

I query also the mantra of "more URI schemes considered harmful". I think
this relates back somehow to the notion that all schemes are variously
dereferenceable and therefore the number of transport protocols that
software agents will need to support should be limited. Instead, if one
considers URI in a broader context as providing a global naming architecture
for resource identification and URIs are recognizable "in context" - then I
see no especial harm in an agent being able to recognize but not action a
given URI.

Received on Saturday, 11 October 2003 04:24:27 UTC

This archive was generated by hypermail 2.4.0 : Sunday, 10 October 2021 22:17:44 UTC