RE: [xri] URIMap element (was: XRD trusted discovery workflow)

Yes.

I wish I wasn’t so distracted the past two days and available to offer my views on this (which are both based and directing the work on /site-meta and XRD), and maybe save you all this very long thread…

At the /site-meta level, there will be a facility to describe URI mapping via a URI template. /site-meta will have a canonical TEXT representation (Mark will hopefully push it out soon) instead of the current XML. XRD will define an XRD-based version of /site-meta so that a GET on /site-meta with Accept: application/xrd+xml will produce an XRD version of the same content (or just return the text format). At this level, templates will need some filtering based on the URI scheme.

The template element itself will need to support 2 attributes: vocabulary and syntax. This will allow any URI template format and any vocabulary. Within XRD, both can be implied from the <Rel> or <Type> of the <Link> (<Service>) but this is more true for vocabulary than syntax. I will send a full walkthrough tomorrow which will help understand how all this will work.

The most important take-away is that it doesn’t matter what you start with (mailto, http, im, etc). /site-meta will map any URI to the HTTP URI of the descriptor. Once you get an XRD file, you continue the same way.

EHL

From: Drummond Reed [mailto:drummond.reed@cordance.net]
Sent: Thursday, December 11, 2008 12:12 PM
To: xri@lists.oasis-open.org
Subject: [xri] URIMap element (was: XRD trusted discovery workflow)

My takeaway from the recent URIMap discussion is that there are two “levels” where we need URI mapping.

The first one is at the XRD level (the site-meta level). The use case here is, “I have URI X and I need to find the XRD for it.” Finding that XRD can require requesting the site-meta file and then using it’s URIMap to find the XRD (I understand site-meta may not be XML so it may not have a URIMap element, but it would be whatever the URI mapping equivalent is).

The second level is following a link from one XRD to a related resource. The use case here is, “I have the XRD for URI X and now I want the URI Z for the resource whose relation is Type Y”. Computing URI Z from URI X can require a URIMap.

It seems that for the first level, the URIMap element should be in the /site-meta file (or the XRD that serves that role if we support that option).

For the second level, the URIMap element should be a child of <Service> (or <Link> if we call it that).

Do I have this right?

=Drummond

From: sappenin@gmail.com [mailto:sappenin@gmail.com] On Behalf Of David Fuelling
Sent: Thursday, December 11, 2008 11:36 AM
To: Dirk Balfanz
Cc: Brian Eaton; xri@lists.oasis-open.org
Subject: Re: [xri] XRD trusted discovery workflow

On Thu, Dec 11, 2008 at 7:10 PM, Dirk Balfanz <balfanz@google.com> wrote:

I do think that something like

<Service>
<Type>uri-to-uri-map</Type>
<URIMap>...</URIMap>
</Service>

doesn't make much sense b/c both the <Type> element _and_ the <URIMap> element say that this is a URI map. We don't need to say it twice.

I disagree. The <Type> describes the service (It's a way to map URI's, e.g.). The URIMap is the way you go about mapping the URI.

If you omit the <Type>, then how does an XRD consumer know that the URIMap is supposed to be used to map URI's to URL, instead of doing something with some other Service-Type, like OpenID.

As an example, these two Services are very different, despite having the same URIMap.

<Service>
<Type>http://xrd.something/GenericURIMap</Type>
<URIMap>http://example.com?uri={uri}</URIMap>
</Service>

and

<Service>
<Type>http://specs.openid.net/auth/2.0</Type>
<URIMap>http://example.com?uri={uri}</URIMap>
</Service>

xri message