W3C home > Mailing lists > Public > www-tag@w3.org > May 2008

Re: Why I'm against XRIs

From: Dan Brickley <danbri@danbri.org>
Date: Fri, 30 May 2008 22:24:59 +0100
Message-ID: <484070AB.50704@danbri.org>
To: David Orchard <orchard@pacificspirit.com>
Cc: www-tag@w3.org

David Orchard wrote:
> http://www.pacificspirit.com/blog/2008/05/30/detailed_technical_reasons_why_im_against_xris
> Cheers,
> Dave

Nice post. My own discomfort with XRIs comes more from their association 
with patent-wielding mischiefmakers (see
http://danbri.org/words/2008/01/29/266 )... so I didn't spend much time 
on their technical proposal, since there is so much good work around to 
review from better behaved sources. But from what I've read, I agree 
with your analysis.

One puzzle though. You write:

1. HTTP URIs are bound to a specific network protocol. XRIs are by 
definition protocol independent.

Technically, no.  The TAG, in 
http://www.w3.org/2001/tag/doc/SchemeProtocols.html, and Roy Fielding 
have all regularly disputed this.

If the desire is to be protocol independent, then I suggest that there 
are specifications like SOAP and WSDL that are designed for protocol 
independence that are more suitable for achieving that goal. 
Interesting that they aren't that trendy, in large because they are 
protocol independent.  Protocol independence appears to be a bug on the 
web, not a feature.

You seem to be talking here about, more or less, protocol-independent 
(for lack of better word) 'protocols', ie. some form of interfaces or 
service definition that can be mapped to one of several lower level 
transports. Yet the "XRIs are URNs" angle is more about XRIs being 
protocol-agnostic names/identifiers.

Not that I buy the argument. We could dereference http: names through a 
variety of means (including revised/updated http protocols). But I don't 
think that SOAP/WSDL are particularly relevant at this point.



Received on Friday, 30 May 2008 21:25:40 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:22 UTC