RE: Boeing XRI Use Cases

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 Sunday, 13 July 2008 05:18:34 UTC