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.

John Bradley

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):
>> ntax-V2.0-cs.html#_Converting_XRIs_to_URIs
>> 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
>> "" 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 subspace of
>>'s URI space and sets up a corresponding partial
>> redirect so that when a HTTP XRI such as
>> 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
>> perhaps by forwarding the request to a 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
>> "" at the beginning of a URI instead
>   ^^^^^^^^^^^^^^^^^^^^^^^^
> The above should have said "".
>> 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, and there is no absolute guarantee
>> that 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 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  |
>> 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 00:30:07 UTC