Re: Boeing XRI Use Cases

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