- From: Booth, David (HP Software - Boston) <dbooth@hp.com>
- Date: Sat, 12 Jul 2008 03:57:47 +0000
- To: "Schleiff, Marty" <marty.schleiff@boeing.com>, "Ray Denenberg, Library of Congress" <rden@loc.gov>
- CC: "www-tag@w3.org" <www-tag@w3.org>
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