Re: Boeing XRI Use Cases

No problem David.

Marty and I discussed it and thought it was probably a typo.

I took it as intended.

Thanks.
John Bradley
=jbradley


On 11-Jul-08, at 8:57 PM, Booth, David (HP Software - Boston) wrote:

>
> Oops!  I was just informed of a typo below that may have caused
> some confusion . . .
>
>> From: David Booth
>>
>> Marty,
>>
>> I think XRIs have a major adoption problem.  Their special
>> properties are only useful to the extent that machines can
>> recognize them and invoke their special semantics.  And
>> people are not jumping all over themselves to implement new
>> URI schemes in their software.
>>
>> On the other hand, HTTP is ubiquitous.  This is why I believe
>> you will have significantly greater success piggybacking the
>> XRI ideas on top of HTTP URIs, rather than inventing an new
>> URI scheme.
>>
>> I see that the XRI 2.0 spec already defines lossless
>> transformations to and from IRIs (and hence URIs):
>> http://www.oasis-open.org/committees/download.php/15376/xri-sy
>> ntax-V2.0-cs.html#_Converting_XRIs_to_URIs
>> http://www.oasis-open.org/committees/download.php/15376/xri-sy
>> ntax-V2.0-cs.html#_Toc117301857
>> so presumably an absolute XRI reference and its corresponding
>> absolute URI reference could be considered semantically
>> equivalent.  I notice that such a URI reference always starts
>> with the string "xri:", so presumably that string is how
>> XRI-aware software would recognize that the URI is a
>> URI-encoded XRI, and interpret its meaning as defined in the
>> XRI spec.  Surely there is nothing magic about that
>> particular string: if the XRI spec had instead decided on
>> some other arbitrary URI-conformant string such as
>> "fribblejam:", and written the specs accordingly, XRIs would
>> work just as well.
>>
>> Suppose the OASIS XRI technical committee (TC) were to decide
>> to make XRIs more web friendly and lower the barrier to their
>> adoption by writing a second "HTTP-XRI" spec that bases XRI's
>> on http URIs roughly as follows.
>>
>> 1. The new HTTP-XRI spec is written to require the string
>> "http://purl.org/xri/" at the beginning of an HTTP XRI,
>> instead of starting with "xri:".  Aside from this simple
>> syntactic difference, the structure and semantics are defined
>> to be *exactly* the same as for an existing URI-encoded XRI.
>> (Okay, I will admit that some additional %-escaping might be
>> needed also -- I haven't checked the syntax rules in enough
>> detail to know -- but surely that is a technical detail that
>> could be worked out, and does not significantly affect the
>> point of this example.)
>>
>> 2. The TC registers the http://purl.org/xri/ subspace of
>> purl.org's URI space and sets up a corresponding partial
>> redirect so that when a HTTP XRI such as
>> http://purl.org/xri/@boeing.com/(@example%2Fabc%252Fd%2Fef)
>> is dereferenced in a browser, some useful information is
>> returned, perhaps along the lines of:
>>
>>        - General marketing info about HTTP-XRIs, what they
>> mean, how great they are and how to adopt them;
>>
>>        - Specific info about
>> http://purl.org/xri/@boeing.com/(@example%2Fabc%252Fd%2Fef),
>> perhaps by forwarding the request to a boeing.com server; and/or
>>
>>        - Pointers to HTTP-XRI plug-ins or toolkits, to help
>> bootstrap the adoption of XRI-aware software.
>>
>> Some observations:
>>
>> - HTTP-XRI-aware software would merely look for
>> "http://http-xri.org?xri:" at the beginning of a URI instead
>   ^^^^^^^^^^^^^^^^^^^^^^^^
>
> The above should have said "http://purl.org/xri/".
>
>> of looking for "xri:", and thereafter apply the *exact* same
>> processing as it would for URI-encoded XRIs, since HTTP XRIs
>> would have the *exact* same semantics.
>>
>> - Non-HTTP-XRI-aware software would not know about the
>> special semantics of these URIs (just as non-XRI-aware
>> software would not know about the special semantics of XRIs),
>> so it would not be any worse off than for the XRI case.
>> However, the software *might* still be able to retrieve
>> useful information by dereferencing the URI that it could
>> present to the user, which could not be done in the XRI case.
>>
>> - Software that is only *partially* XRI-aware might not have
>> the ability to do XRI resolution -- HTTP resolution is
>> ubiquitous, but XRI resolution clearly is not -- *but* it may
>> still know a little about XRIs and may still be able to make
>> use of some of the information returned by dereferencing the
>> HTTP XRI, which also could not be done for the XRI case.
>>
>> In other words, for the most part, HTTP-XRIs would have
>> virtually the same benefits as existing XRIs, plus they would
>> have additional advantages:
>>
>> - they would be more web friendly (following good web
>> architectural principles of not creating new URI schemes); and
>>
>> - being potentially dereferenceable with HTTP, they could
>> have a significantly lower barrier to adoption as compared
>> with existing XRIs.
>>
>> Of course, as with anything, there is a down side:
>>
>> - The URIs would be a little longer.
>>
>> - A person looking at an HTTP XRI who is not familiar with
>> XRIs may not immediately realize that it has special XRI
>> semantics.  But being potentially dereferenceable, HTTP XRIs
>> could give them an easy way to find out.
>>
>> - Dereferencing by non-XRI-aware software would depend on
>> the stability of purl.org, and there is no absolute guarantee
>> that purl.org will continue to exist and be supported years
>> from now.  On the other hand, there is no guarantee that XRI
>> resolution software will continue to be supported years from
>> now either.  And if I were deciding where to place my bet,
>> I'd say it is *substantially* more likely that purl.org will
>> continue to be supported years from now than that XRI
>> resolution software will continue to be supported, but of
>> course others may think differently.
>>
>> My question: what would you think of the pros/cons of such an
>> approach?
>>
>>
>>
>> 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.
>