- 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
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 UTC