RE: XRI vote aftermath

Ray,

This is one of the most frequently asking questions about XRI. The short
answer is #1.4 on the XRI 2.0 FAQ
(http://www.oasis-open.org/committees/xri/faq.php):

****** QUOTE ******

What is the relationship of XRI to URI and IRI?

URI (RFC 3986) is the IETF/W3C standard for addressing on the Web. IRI
(Internationalized Resource Identifier, RFC 3987) builds on top of the URI
specification by extending the syntax to include Unicode characters. It also
defines a transformation from an IRI into a valid URI for applications that
can only accept URIs.

XRI follows this same model. It builds on the IRI specification by extending
the syntax to include features needed by abstract, structured identifiers
intended to identify resources independent of any specific network location,
domain, application, or protocol. The XRI Syntax specification also defines
a transformation from an XRI into an IRI or URI for applications that only
accept IRIs or URIs.

***** ENDQUOTE *******

To go deeper, the answer is that it depends on the _form_ of the XRI. A
native XRI is not technically a URI just as a native IRI is not technically
a URI. But the IRI spec defines a transformation of a native IRI into a URI.
The XRI spec defines a transformation from a native XRI into an IRI (since
XRI uses the full IRI character set), and then from that point the IRI spec
governs the transform into a URI.

Secondly, when transformed into an IRI or a URI, XRIs do use the "xri:"
scheme. On that point, the XRI TC has always intended to register this
scheme with IANA. On advice of OASIS staff, we were waiting to do this until
XRI had become an OASIS Standard, as that would support the IANA
application. 

So in conclusion, native XRIs -- which are not required to use the "xri:"
scheme component because in many contexts they can be distinguished by the
initial global context symbol -- are fully abstract structured identifiers
as you describe. But any native XRI can be downcast into an IRI or URI for
compatability with IRI/URI infrastructure.

Hope this helps,

=Drummond 


> -----Original Message-----
> From: www-tag-request@w3.org [mailto:www-tag-request@w3.org] On Behalf Of
> Ray Denenberg, Library of Congress
> Sent: Friday, June 06, 2008 6:48 AM
> To: Schleiff, Marty; Henry S. Thompson
> Cc: www-tag@w3.org
> Subject: Re: XRI vote aftermath
> 
> 
> The most perplexing aspect (to me) of this whole XRI business is the
> discussion of URI schemes.  I was sure we had established that XRI is not
> a
> proposed URI scheme, it is something else, a higher-level identifier, or
> something (actually I don't think it has ever been definitively
> characterized in terms of its relationship to a URI scheme.)
> 
> Yet the discussion still seems to center on  "[T]he unbounded registration
> of new schemes ...".
> 
> What am I missing?
> 
> --Ray
> 
> ----- Original Message -----
> From: "Henry S. Thompson" <ht@inf.ed.ac.uk>
> To: "Schleiff, Marty" <marty.schleiff@boeing.com>
> Cc: <www-tag@w3.org>
> Sent: Thursday, June 05, 2008 5:53 PM
> Subject: Re: XRI vote aftermath
> 
> 
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Schleiff, Marty writes:
> 
> > I'll start by asking for help to understand the TAG's stance on
> > introduction of new URI schemes. I understand the part about it being
> > costly to introduce new schemes. What I wonder about is the idea that
> > the http: scheme should be used for everything (I probably didn't state
> > that very well - perhaps you can put it into better words).
> >
> > If there existed no mailto:, or ldap:, or https: scheme today (the three
> > I'm most familiar with beyond http:), what would be the TAG's reaction
> > to a request for a new scheme for mailto: or ldap: or https?
> 
> I am not speaking for the TAG, only myself, in this, but the core of
> my answer is in fact from the IETF [1]:
> 
>   "[T]he unbounded registration of new schemes is harmful.  New URI
>    schemes SHOULD have clear utility to the broad Internet community,
>    beyond that available with already registered URI schemes."
> 
> I simply don't think that's true for XRIs.  In trying to explain this
> to someone else, before reading your email, I actually used Boeing as
> an example:  I believe it's the case that most desktops in Boeing (and
> there are a _lot_ of them) are centrally managed and tightly
> constrained, with a multi-year roll-out cycle.  That means that no-one
> at Boeing will be able to click on an xri: or hdl: or doi: URI for at
> _least_ three years, given that IE7 does not support any of those out
> of the box.  "So," I said to my interlocutor, "do you really want to
> recommend that your users use URIs which no-one at Boeing, or dozens
> of other similar companies, can click on for years to come?"
> 
> Yes, this is an argument against _any_ new URI scheme where there is
> real value to be gained by allowing as many people as possible to use
> it to access resources on the Web.  And the network effect (because
> that's what we're talking about) is what _made_ the Web.  Using a new
> URI scheme when you could use http: is intentionally cutting yourself
> off from the network effect.
> 
> I think that mailto: is pretty clearly _not_ in that category, and
> its non-retrieval semantics makes it a reasonable special case.  And
> https: is really just http: with a bit of metadata encoded in the
> scheme name.  ldap: is a less clear case -- I'm not really familiar
> with its operation, but my superficial understanding is that it is not
> central to the functioning of the LDAP system, and that its semantics
> mean that it is unlikely that it will appear in general-purpose Web
> contexts, which distinguishes it pretty well from http:.
> 
> The TAG is working on a detailed exposition of its position in this
> matter, which I expect will address your question in more detail -- I
> hope this quicker personal reply will be helpful in the meantime.
> 
> ht
> 
> [1] http://tools.ietf.org/html/rfc4395
> - --
>  Henry S. Thompson, HCRC Language Technology Group, University of
> Edinburgh
>                      Half-time member of W3C Team
>     2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440
>             Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk
>                    URL: http://www.ltg.ed.ac.uk/~ht/
> [mail really from me _always_ has this .sig -- mail without it is forged
> spam]
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.6 (GNU/Linux)
> 
> iD8DBQFISGBakjnJixAXWBoRAg5xAKCCtOGlabdVqMUj7VT3uV47nxOFbQCePoUr
> Uyf5aybDYwSd1lBh1h9edRQ=
> =2ENu
> -----END PGP SIGNATURE-----
>

Received on Saturday, 7 June 2008 16:32:39 UTC