FW: Updates to URNs, Namespaces and Registries

[Forwarding this for archiving.  I already sent these comments directly
to Dave and Henry.]

-----Original Message-----
From: Booth, David (HP Software - Boston) 
Sent: Thursday, August 24, 2006 3:01 PM
To: 'David Orchard'
Cc: Henry S. Thompson
Subject: RE: Updates URNsRegistries

Hi Dave,

I took another look at sec 4 and 5 of 
http://www.w3.org/2001/tag/doc/URNsAndRegistries-50.xml
Comments (in sequential order, not ordered by importance):

1.  Sec 4.3, first sentence: s/know/now/

2. Sec 4.3 and 4.4: I really think you need to clearly separate out and
separately address the two concepts:

	- persistence of the URI as an *identifier*, for which the
criterion is whether the URI continues to identify the same resource;
and

	- persistence as a dereferenceable *location*, for which the
criterion is whether the URI continues to be dereferenceable to useful,
reliable information.

At present, sec 4.3 discusses "Persistence of Identifiers", but it does
not clarify that it is *only* addressing the URI's role as an
identifier, nor does it give the criterion for being persistent.  And
sec 4.4 says:
[[
There is no benefit to the xri: versus http: as the work in examining
the XML document and XML namespace specifications are the same.
Alternatively, they may try to dereference the namespace name, but it's
not deferenceable so they get no information.
]]
but this is about the use of the URI as an *identifier*, not as a
dereferenceable *location*.

3. Sec 4.4 also lists "3 separate scenarios", but I don't understand the
relevance of #1 ("an identifier can be created in a decentralized
manner") to dereferenceability.  Also, I don't understand why this would
be different between http URIs and oasis URNs anyway.  Can't Oasis mint
their own urn:oasis:... URNs without individually registering every one
of them?

4. Sec 4.4:
I don't understand the relevance of the last paragraph:
[[
In the http: identifiers, the authority is specified immediately after
the scheme. The authority system in http: URIs is the internet's DNS and
IP systems. One or more DNS authorities produces an IP destination as
the final authority. That authority is then sent the remaining part of
the URI for dereferencing. In the case of
http://docs.oasis-open.org/ws-rx/wsrm/200602, the HTTP interaction is
. . . 
]]
The URNs are not dereferenceable, period.  So why does authority matter
in a section on dereferenceability?

5. Sec 4.5:  s/Erroneous/Misleading/ in the section title.

6. Sec 4.5: s/But as there is no document dereferencable/But if there is
no document dereferencable/

7. Sec 4.5:
I don't think you are applying the right line of argument here.  The
argument that an http URI should only be seen as dereferenceable if it
is inside an <a href=... > tag is somewhat specious.  People often
intend a URI to be dereferenceable even when it does not appear as
clickable in a browser.  And I don't think the statement "Thus the
context of usage has incorrectly view the xmlns attribute as HTML" is
really correct.  The user *is* doing the right thing in attempting to
dereference any http URI, even if that attempt is unsuccessful.  The
only thing that would be incorrect is if the user *depends* on the URI
being dereferenceable when it is a namespace URI.

I think the point here should be that http URIs may create a misleading
expectation of dereferenceability, but the namespace spec is clear that
apps must not depend on them being dereferenceable.  Thus, a user
attempting to dereference one is gambling 5-10 seconds on the chance
that it actually *is* dereferenceable.  If the URI owner follows the
WebArch advice and makes it dereferenceable, then the user wins the
gamble; otherwise the user loses 5-10 seconds.  On the other hand, with
a URN, the user knows that he/she can *never* win the gamble (i.e.,
successfully dereference the URI) and thus does not even try, therefore
saving 5-10 seconds in those cases where the http URI turns out not to
be dereferenceable.

8. Sec 4.6:
The final paragraph looks good now.  But I have trouble with some of the
language in the first paragraph:
[[
Any use of an identifier, or any datatype for that matter, in an XML
document has the same issues. A provider of a identifier must specify
how the identifier will be used in each specific sub-context of their
XML language, whether it is intended as an identifier, a location, or
both.
]]
I suggest changing this to:
[[
Any use of a URI in an XML document has the same issues. URI owner must
specify how the URI is intended to be used, whether it is intended as an
identifier, a location, or both.
]]

9. Sec 5.1:
s/this scenarios/these scenarios/

10. Sec 5 in general:
This section seems to be comparing the merits of the two URIs:
http://department.agency.example.org/docs/govdoc.pdf
xri://@example.org*agency*department/docs/govdoc.pdf
But these are not the right URIs to compare.  One of these URIs was
designed to provide identity persistence and location independence (the
xri URI); the other was not (the http URI).  There are two consequences
of this: 

	- The section is far longer and more bogged down in detail than
needed.  In essence, the arguments you make in support of http URIs are
just swatting at the branches of the issue, rather than cutting it down
at its trunk.  

	- An additional benefit is wrongly attributed to xri URIs.
Specifically, the section says that the http URI incurs an addition GET
when a document has moved.  However, if you follow the recipe in
http://dbooth.org/2006/urn2http/  , there is no need for an additional
GET, because the party dereferencing the URI can use the XRI protocol
when dereferencing the http URI.

In general, the comparison in section 5 should be between an http URI
that was *designed* to have the features of identity persistence and
location independence, versus an xri URI that was also designed to have
these features.  

Thanks

David Booth, Ph.D.
HP Software
dbooth@hp.com
Phone: +1 617 629 8881

Received on Tuesday, 5 September 2006 15:59:09 UTC