Re: Comments on draft-hollenbeck-ietf-xml-guidelines-02.txt

On Tue, Apr 30, 2002 at 12:15:07PM -0700, Tim Bray wrote:
> Michael Mealling wrote:
> >> http://www.textuality.com/tag/Issue8.html
> >>To summarize the case against URNs: It's good for namespace documents 
> >>exist, and it's good for them to be available, and most people can't 
> >>dereference URNs.  -Tim
> >
> >But doesn't all of that depend on the application? Let's assume that
> >the CNRP group updated the CNRP specification and made it into
> >a namespace. The IETF has been pretty much opposed to putting 
> >document locations like that in standards (for good reasons that
> >some in the W3C might disagree with). The CNRP Working Group would
> >use a URN as a way to ensure that the name _NOT_ be dereferenced
> >through the IETF or IANA web sites but instead through some local
> >catalog/EntityResolver.
> 
> So if I don't have one handy, as most people don't, I'm going to have to 
> do some real work to track down the documentation.  Why is this better?

Because it doesn't create a single point of failure for when that
resource is no longer available. This probably won't be a consideration
for most things but for highly used protocols it very well could be 
an issue.

> >I.e. we want to use URNs specifically because they're not usually
> >dereferenced and we have good and valid reasons for not wanting to do that.
> 
> OK, we agree, if you explicitly don't want people to dereference the 
> names, then using URNs is appropriate.  Our experience has been that 
> dereferencing the names to get explanatory material is very helpful, but 
> perhaps that experience is not relevant in this domain.

Yes. I think saying they're always bad is the problem. Like I said, the
TAG should be agnostic with respect to specific schemes but layout the
pros and cons of particular scheme semantics: i.e. dereferencing is 
good but it can create expectations and single points of failure that
may be an issue for some applications. This way people don't take this
statement to just a littel farther and build parsers that assume things
like all XML Namespace names start with 'http:'.

> >Hmm.... looking at your document the logic used to get to the idea that
> >URNs are bad for Namespace names is kind of circular. You assume that
> >since a large portion of people use 'http:' scheme namespace names that
> >those users might think they are retrievable. Since there is that
> >assumption then we should all use 'http:' scheme names.
> 
> It's simpler than that.  People picked the http: names first, then 
> thought they might as well put something there, and that turned out to 
> be useful.  Since it turns out to be useful, we conclude that http: 
> names are the way to go.

Weeeelll, the evidence I've seen suggests that there are a _large_
number of people using URNs as namespace names instead. I think every
single namespace used in MS Office uses a URN (albiet an unregistered one!)
I think every web services example from IBM I've seen is using them.

> > What if 
> >I _DON'T_ want the namespace name to be resolvable
> >by a conscious decision?
> 
> Then use a URN.

Good. That's what I was after.... ;-)

> >Even still you also assert that namespace names aren't frequently 
> >dereferenced at run-time. So the value of saying URNs are bad is even less 
> >evident.
> >Either they're dereferenced or they're not....
> 
> There are two cases in which we see them being dereferenced: (1) by a 
> human wondering "what is this namespace about?" or "I thought I knew 
> this stuff, what the hell is a <cnrp:x35> tag?" - this doesn't happen at 
> run-time.  

Yes. This is the most common usage I've seen. In that case using any
managed namespace is probably sufficient since there will be ways of
finding out about it. 

> (2) by an application at run-time - this isn't something I 
> care about much but the SemWeb people are all excited about it.  I agree 
> that run-time dereferencing would be really unlikely at the protocol level.

Yep. I don't think my CNRP client will be doing it but my semantic
web utility might and in that case it will be DDDS aware so it will be
able to resolve any URI (both authoritatively and contextually).

> >I guess for me (and many on the URI-IG Group) the question comes down to 
> >this:
> > are URIs generic for the web or not?
> 
> URNs and what we used to call URLs are far from equivalent in their 
> design goals and usage characteristics.  Is it not reasonable to assert 
> that for certain application classes, one side or the other is a better 
> fit?

Yes and no. I think the best thing is to discuss the actual semantics
that are desirable and leave the choice of the actual namespace up to the
application designer. I.e. 

"It is a good thing that XML Namespace Names are dereferencable for 
pedagogical and support purposes but it is not required that they be so. 
Thus XML Namespace Names should be chosen from URI schemes that are 
derefereneable. But in the case where there is no need to do so then 
any URI scheme is valid."

> >P.S. I though the TAG was going to defer to the URI group URI related 
> >issues? At least that's they way it was represented to me....
> 
> It increasingly seems like *everything* is a URI-related issue.  Only 
> half kidding. -Tim

My favorite definition for the web was one TimBL used a long time ago:
"The Web is the set of 'things' that can be identified by a URI" (and that
included physical objects!).  So, while you're only half kidding, I actually 
prefer the idea. ;-)

-MM

-- 
--------------------------------------------------------------------------------
Michael Mealling	|      Vote Libertarian!       | urn:pin:1
michael@neonym.net      |                              | http://www.neonym.net

Received on Tuesday, 30 April 2002 16:17:12 UTC