Re: Boeing XRI Use Cases

On 15-Jul-08, at 8:39 AM, Julian Reschke wrote:

> John Bradley wrote:
>> ...
>> It is my belief that there is no place in the spec where xri: is  
>> used as a XML namespace name that a URL could not have been used.
>> <XRD version="2.0" xmlns="xri://$xrd*($v*2.0)">
>> This uses the XRI versioning syntax that we have some attachment to.
>> David Orchard has concerns that this is not a valid URI.
>> ...
> Well, it isn't, until you register "xri" as a URI scheme. I think  
> this is why many people are concerned by this: that "xri"  
> identifiers leak out into places that do only allow U^HIRIs.
>> That is one question I don't think has been resolved completely.
>> If the scheme were registered is this valid as a URI without  
>> further escaping?
> Potentially.
> Why does it start with "//" when it doesn't use an authority (see  
> RFC3986, Section 3)?
There is a authority segment it is a two subsegment XRI  $xrd is the  
first sub segment and ($v*2.0) which is a cross reference is the second.

A more typical XRI in URI-Normal form looks like xri://=jbradley/ 
+phone/+home.  =jbradley is the authority and +phone/+home is the path.

It is a big spec and I won't dig into it in detail here.

To be frank I have wondered myself if leaving the double slashes off  
might make the scheme more acceptable for people.


The only thing it changes os that URI processors would be less tempted  
to try and examine the authority segment.

The XRI-TC believe that including the indication of an authority  
segment is the more correct thing to do.

This would be a great thing to drill down on if people have the  

If there is no hope of preserving xri: as a scheme with or without an  
authority segment then the discussion would be a bit academic.

>> ...
>> My question around WEBDAV was not really directed at XML but rather  
>> the processing by WEBDAV aware clients of webdav URLs in the http:  
>> scheme?
>> WEBDAV extended the operators beyond GET and POST, and had a  
>> extended web server that dealt with information encoded in the path.
> No, in WebDAV there is no information encoded into the path. It only  
> uses additional methods, the HTTP URLs are the same as always.
>> We have not proposed new operators to extend the http protocol with  
>> HXRI.
>> If xri and webdav and http are to all share the same http: scheme  
>> addressing then how are the clients like XDI servers and possibly  
>> web browsers going to recognize these URIs?
> Are you asking for feature discovery? WebDAV does that through  
> OPTIONS (see < 
> >).
>> Is there something we can learn from others attempts to fit  
>> themselves into the http: scheme?
>> Some people feel that if we conform to http: scheme addressing we  
>> must still justify XRI in some way.
>> How have other people met this challenge?
>> I ask about WEBDAV because it would appear to have some of the same  
>> issues we will encounter tying to re-use the http: scheme.
>> I will have a look at RFC 2518 to see if it can shine some light on  
>> this.
>> ...
> I don't think WebDAV shares these issues, as it just adds new  
> methods to  manipulate otherwise standard HTTP resources. That being  
> said, you want to look at RFC 4918, not RFC 2518.
> BR, Julian
So a client must do a get on the URL first to discover if it is WEBDAV?

I can see how that would work for HXRI in some but not all  

I do think that we need a way for clients to recognize HXRI so that  
they can be converted to UTF-8 for display and other processing.

Thanks for your input.

John Bradley

Received on Tuesday, 15 July 2008 16:56:17 UTC