Re: Boeing XRI Use Cases

Hi David,

Sorry my dyslexia this time, I intended purl.org.

I have added comments inline.

On 12-Jul-08, at 10:15 PM, Booth, David (HP Software - Boston) 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?
>
True,  it could.  The idea was to allow people to run there own XRI  
proxy resolvers as needed.
Boeing could have http://xri.boeing.com if they liked as a proxy  
server and applications could draw an inference from the http:/xri.  
and the first characters of the path to determine if it is a hxri.

Finding a way for people to use there own proxy resolvers is something  
I would like to keep.
I am open to alternate suggestions.

Registering http://purl.org/xri/ and redirecting it to a proxy at  
xri.net has some issues with SSL certificates.
If the security could be sorted out and purl.org is OK with taking the  
traffic having that URL would be fine.

I think that https://xri.net/ is the best prefix for  
interoperability.   XRI aware software could always redirect queries  
to a local resolver by configuration.

I think that this could be quickly resolved with some mutual thought.

>> [ . . . ]
>> 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.
>
This would be fine if the SSL issues could be sorted out.

>>
>> 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.
>
We created XRI to bring information previously unavailable to the web  
from SQL and other sources into the URI information space through XRI  
and XDI.

We haven't talked too much about XDI, but it is intended as an  
abstract data interface using XRI addressing to provide a distributed  
ODBC like interface for web applications.

The goal with XDI is to reduce the need for creating a method  
invocation API that needs to be rewritten every time the underlying  
data schema changes.

Yes there are similarities to to SPARQL but there are also many  
differences, they are complimentary in many ways.  My company ooTao is  
considering implementing a SPARQL interface for our XDI server.

XRI and native XRI resolution with cross references is fundamental to  
the architecture of the XDI protocol.

If we were mistaken and mapping this information into the URI space  
should be done within the http: scheme, rather than by creating a xri:  
scheme,  I am more than willing to accommodate this with changes to  
the spec.


>> [ . . . ]
>> 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.
>
>
If the TAG agrees:
1. That native XRI resolution for the purposes of the applications  
that want to use it like openID is OK.
2. That using HXRI through http: proxies is the way that XRI should be  
mapped into the URI information space.
3. That the xri: form will not be used as a URI.

Then I think we have the beginnings of an understanding and compromise.

I eagerly await feedback from the TAG.

Could the TAG please enumerate any issues other than the above that  
they see as show stoppers?

Thanks for your help and interest in this matter David.

Best Regards
John Bradley
OASIS IDTRUST-SC
=jbradley
http://jbradley.myplaxo.com/

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