W3C home > Mailing lists > Public > www-tag@w3.org > April 2003

Re: namespaceDocument-8: possible interaction with Namespaces in XML 1.1

From: Norman Walsh <Norman.Walsh@Sun.COM>
Date: Fri, 11 Apr 2003 11:27:57 -0400
To: www-tag@w3.org
Message-ID: <87r8895a0y.fsf@nwalsh.com>

Hash: SHA1

/ Tim Bray <tbray@textuality.com> was heard to say:
| Yes and yes, but I believe this might be difficult to achieve.  The
| TAG seems to be quite broadly unenthusiastic about URNs but they have
| enthusiastic partisans in the community.

Yeah. And on the TAG, too, even if in distinct minority :-)

|> Q2: Your text "URNs are not effectively usable" might lead me to believe
|> that there might be an effort ongoing to standardize how to retrieve
|> resources using URNs.  Do you know of such an effort?
| Yes, there are such efforts in the IETF; the acronym doesn't spring to
| mind, but that doesn't matter, because I'm sure that several other
| people will spring forward to explain why URNs are in fact retrievable
| and that TimBL and I are blowing smoke when we claim they're not.  I
| accept that mechanisms in principle exist to dereference URNs, it's
| just that I've never used a computer where such software was
| installed, so it's clearly far from ubiquitous.

Others have made those points, so I won't. There's also "OASIS
Extensible Resource Identifier (XRI) TC"[1] but I haven't looked at

It will come as no surprise to Tim that I second Larry's observation:

  In the long run, I think it's easier to make a URNs retrievable than
  it is to make HTTP URLs permanent, and that the W3C should stop
  trying to make an anti-URN policy.

                                        Be seeing you,

[1] http://www.oasis-open.org/committees/xri/

- -- 
Norman.Walsh@Sun.COM    | It is not impossibilities which fill us with
XML Standards Architect | the deepest despair, but possibilities which
Web Tech. and Standards | we have failed to realize.--Robert Mallet
Sun Microsystems, Inc.  | 
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.7 <http://mailcrypt.sourceforge.net/>

Received on Saturday, 12 April 2003 10:02:03 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:32:37 UTC