- From: David Orchard <orchard@pacificspirit.com>
- Date: Mon, 14 Jul 2008 14:44:21 -0700
- To: "Booth, David (HP Software - Boston)" <dbooth@hp.com>
- Cc: "John Bradley" <john.bradley@wingaa.com>, "Schleiff, Marty" <marty.schleiff@boeing.com>, "Ray Denenberg, Library of Congress" <rden@loc.gov>, "www-tag@w3.org" <www-tag@w3.org>
- Message-ID: <2d509b1b0807141444h42861504g429afc2adbf68395@mail.gmail.com>
My objections would be removed with those 2 changes. Cheers, Dave On Sat, Jul 12, 2008 at 10:15 PM, Booth, David (HP Software - Boston) < dbooth@hp.com> wrote: > > Hi John, > > > From: John Bradley [mailto:john.bradley@wingaa.com] > > [ . . . ] > > There are actually separate specs for XRI syntax and resolution. > > This is common with OASIS specs. > > > > http://www.oasis-open.org/committees/download.php/15376/xri-sy > > ntax-V2.0-cs.html > > http://docs.oasis-open.org/xri/xri-resolution/2.0/specs/cs01/x > > ri-resolution-V2.0-cs-01.html > > > > I suspect that you may not have read the resolution spec. > > Correct. Thanks for telling me about it. > > > > > I would point you to Section 11 of the resolution spec that in large > > measure deals with your suggestion. > > I skimmed through it (though not in great detail), and it looks like an > effort has been made toward making it implementable over HTTP. And although > that sounds like it would benefit your users, it does not address my key > concern: the creation of a new URI scheme. > > Also, I note in section 11.2, that an HXRI is intended to be recognizable > by starting with "http://xri." (or "https://xri."). Wouldn't this > potentially cause a regular (non-HXRI) URI that happens to start with that > sequence to be erroneously interpreted as an HXRI? > > > [ . . . ] > > I don't know if there is something special about [purl.org] that makes > > it more likely to continue running a proxy resolver than the current > > operators of the XRI Global Registry Service. > > Purl.org (not perl.org) is run by OCLC, "a nonprofit membership > organization serving more than 69,000 libraries and cultural heritage > institutions in 112 countries". From their site: "OCLC has fiduciary > responsibilities of the highest order. We assist our members in organizing > and preserving the human record, providing access to it, and passing it on > to future generations." > > I suggested purl.org (not perl.org) as an example, only because: (a) I > know it has credibility in its commitment to maintain persistent URLs; (b) > it is widely regarded as a neutral party; and (c) it is the most well-known > way to create persistent URLs. However, the XRI TC could just as well > choose something else. > > > [ . . . ] > > If there is some other arrangement for the proxy resolvers operation > > that would make people more comfortable then we should open that > > discussion, . . . . > > Purl.org only does URL forwarding -- it would not act as an XRI proxy > resolver -- but it could *forward* HTTP requests to an XRI proxy resolver. > > > > > If we: > > 1. Use http://xri.net/=some-xri as the scheme for URLs through a > > proxy resolver. > > 2. Use =some-xri as the normal form for native resolution > > 3. Stop using xri://=some-xri as a IRI > > > > Would this be satisfactory to remove the TAGs objections? > > I am not on the TAG, but from my perspective, #3 alone would remove my > objections. My sole objection is the creation of a new URI scheme. It is > not necessary for obtaining the benefits of XRIs, it creates a higher > barrier to use that http URI, and it is harmful to the web. > > I want to stress that the point of my suggestion to piggyback XRIs on top > of http URIs was *not* to suggest that all XRI resolution should go through > an HTTP proxy or even use the HTTP protocol. My points are: > > 1. An http URI can still act as an XRI identifier even if the HTTP protocol > is not used in resolving it. XRI-aware software could recognize a > http://xri.net/ or http://purl.org/xri/ prefix and use XRI's special > resolution rules without using HTTP at all, thus obtaining all of the > benefits of XRIs that you value. > > 2. An http URI will work better in *other* circumstances, for software that > is *not* yet XRI aware or only partially XRI aware, because it can > potentially be dereferenced using good old HTTP. Think of http URIs as > offering graceful degradation: for software that is not (or only partially) > XRI aware, it can *still* get some potentially useful information by > dereferencing the URI, wherease with the xri: scheme, the software is > *totally* stuck. > > > [ . . . ] > > I believe, and please correct me if I am wrong in my belief > > from last > > weeks call that the TAG position is, (I am paraphrasing now): > > 1. There should be no new URI schemes registered. > > 2. The http scheme should be the only namespace, to prevent > > fragmentation. > > > > I ask simply is this the bar we must meet? > > (Again, speaking for myself -- I am not on the TAG) Yes. It is as simple > as that. > > > > David Booth, Ph.D. > HP Software > +1 617 629 8881 office | dbooth@hp.com > http://www.hp.com/go/software > > Statements made herein represent the views of the author and do not > necessarily represent the official views of HP unless explicitly so stated. > >
Received on Monday, 14 July 2008 21:45:04 UTC