RE: Boeing XRI Use Cases

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.

Received on Saturday, 12 July 2008 04:04:41 UTC