W3C home > Mailing lists > Public > www-tag@w3.org > July 2002

Re: TB16 Re: Comments on arch doc draft

From: Michael Mealling <michael@neonym.net>
Date: Tue, 2 Jul 2002 10:01:43 -0400
To: Tim Bray <tbray@textuality.com>
Cc: www-tag@w3.org
Message-ID: <20020702100143.A1113@bailey.dscga.com>

On Mon, Jul 01, 2002 at 10:33:46PM -0700, Tim Bray wrote:
> Michael Mealling wrote:
> >  Either the web architecture is URI scheme agnostic or it isn't. If
> >the TAG is coming up with architecture that is scheme dependent then
> >IMNSHO, its broken.
> 
> Various flavors of URIs have varying characteristics, including whether 
> or not they are readily dereferenced.  Is it not in-scope for the TAG to 
> say that "for this particular application of URIs, a form that is 
> readily dereferenced should be used"?

Yes. That is perfectly in scope. Specify the particular application requirement
and then say why URI schemes that have such and such a semantic are
preferred over others. You can make that statement and never mention
a particular URI scheme. In many of the cases where people are using
'http:' they could just as easily use 'ftp:' because it has the almost
exact same semantics. 

> >  And, dammit, URNs are dereferencable 
> 
> I do not know about any URN dereferencing software on any of the 
> computers I use at home or at work; this is quite a lot of computers of 
> many different flavors.  

None of my computers came with RDF parsers, Web Services software, Semantic
Web datastores, XML databases, etc either. Does that make them non-useable
and not parts of the architecture? If we use this rule then we shouldn't
even be attempting something new because, well, it doesn't exist right now
so that means it can't be done.

> I've never worked with anyone, or with any 
> software, that can routinely dereference a URN.  I'm prepared to believe 
> that URNs are dereferencable in principle; I find it hard to believe, 
> based on the evidence I see, that this is easily done by ordinary people 
> with ordinary tools.

There have been many cases within the W3C where communities have been
ready to use URNs and even dereference them in certain cases but the
rhetoric from Tim and a few others has turned them back around. I readily 
admit that URN resolution software isn't as widespread as I'd like it to be
but I readily lay that at the feet of those who routinely offer up this
same FUD in response. If that same stumbling block were put in front 
of every other W3C group we would still be stuck with Tim's line mode
browser. 

> So could you please expand on your argument.  Are you arguing that 
> dereferencability in principle is good enough, and it's OK to place the 
> onus on someone encountering one of these for the first time of doing 
> the research to find out how one might go about finding the software to 
> install and perform the dereferencing?

Depending on the application, dereferenceability is not required and
URNs make the most sense out of anything out there. There's a reason
Microsoft put them all over their Office suite. In the case where
dereferencability is a requirement, there are different flavors which
depend on the applications requirements. Contextualized resolution (local 
catalogs, enterprise local copies, etc) is one very important version
of that. In _many_ cases people don't want to dereference a URN (or even
URIs) to their authoritative location. Instead they want it dereferenced
to their local copy.

In the case where someone wants to dereference a URN in a 'default',
authoritative manner the DDDS based URN Resolution system provides just
such a system. The IANA is delegating the uri.arpa zone and many
URN namespace registrants are writing software and investigating how
to organize the delegation rules within their namespaces. For a list
of current and proposed URN namespaces see http://uri.net/urn-nid-status.html.

> Or am I missing the boat on URNs and is it the case that I'm in a 
> minority in my current inability to dereference URNs?

You are not in a minority. But you are also in a minority on having
lots of XML software on your machine. Most people don't have RDF parsers
or XML databases or web services clients. You simply can't keep claiming
that because you personally do or don't have some piece of software
that you are going to use that to determine the web architecture.

> Actually, I don't think that the TAG needs to beat up on URNs to achieve 
> its goal in this particular case; we should just say that namespace 
> names SHOULD be URIs that may readily be dereference, and when 
> dereferenced, yield human and machine readable information about the 
> namespace.  When the time comes that URNs (or any other URI scheme) are 
> easily dereferenced, they'll make good namespace names.   Right now, 
> URNs do not make good namespace names. -Tim

That's getting better. But the TAG should also realize that there are many 
cases where dereferenability of namespace names is exactly _NOT_ what the
system being designed wants to happen. When you have a very significant 
number of people who have very valid reasons to not follow a SHOULD
recommendation in a standard then its usually the case that you need to
remove the SHOULD and elaborate on the pros and cons of the two 
approaches. That way implementors can make informed decisions for 
themselves (unless that's not what you want them to be able to do).

-MM

-- 
--------------------------------------------------------------------------------
Michael Mealling	|      Vote Libertarian!       | urn:pin:1
michael@neonym.net      |                              | http://www.neonym.net
Received on Tuesday, 2 July 2002 10:03:26 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:47:09 GMT