Blogs against XRI

["Schleiff, Marty" <marty.schleiff@boeing.com>]

FYI ...

Marty.Schleiff@boeing.com; CISSP
Associate Technical Fellow - Cyber Identity Specialist
Information Security - Technical Controls
(206) 679-5933

-----Original Message-----
From: Dan Brickley [mailto:danbri@danbri.org] 
Sent: Friday, May 30, 2008 2:25 PM
To: David Orchard
Cc: www-tag@w3.org
Subject: Re: Why I'm against XRIs


David Orchard wrote:
> http://www.pacificspirit.com/blog/2008/05/30/detailed_technical_reason
> s_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.

cheers,

Dan

--
http://danbri.org/