OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [xri] Quick overview of descriptor discovery flow


Title: Re: [xri] Quick overview of descriptor discovery flow
Let me post my follow up overview of the schema and see if that helps.

EHL


On 12/15/08 1:54 PM, "Brian Eaton" <beaton@google.com> wrote:

One other thing - Eran, would you be willing to flesh this out with
some sample syntax for portable contacts and/or OpenID?

If we're just talking about how to find the metadata, it's all a
little too meta for me to follow.  Would something like this be used
for PortableContacts?

<XRD>
   <Link>
       <Rel>portable contacts</Rel>
       <MediaType>portable contacts media type</MediaType>
       <Uri>http://www.example.com/poco</Uri>
   </Link>
</XRD>

Cheers,
Brian

On Mon, Dec 15, 2008 at 12:55 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
> The following method describes how to perform R-URI --> D-URI: finding the
> descriptor URI from the resource URI. The process starts with a resource
> URI. It doesn't matter how that URI has been obtained. In the examples
> below, 'D-URI' is used to indicate the placeholder containing the desired
> descriptor URI.
>
> 1. Method selection
>
> The consumer (entity performing discovery) has three options based on
> information available to it with regard to the resource:
>
> * If the resource is known to be an HTML or ATOM document, and the document
> has been and will be retrieved via HTTP GET either way, the consumer can
> look for <Link> elements:
>
>     <Link href=""D-URI"" rel="describedby" type="application/xrd+xml">
>
> * If the resource is going to be retrieved via HTTP GET/HEAD, the consumer
> can look for Link: headers:
>
>     Link: <D-URI>; rel="describedby"; type="application/xrd+xml"
>
> * If the first two options are not applicable, the consumer obtains the
> /site-meta document for the resource's domain. The consumer may request an
> XRD representation but must be able to parse the text representation. It is
> not clear if there is real value in offering an XRD representation of
> /site-meta (please discuss).
>
> Text:
>
>     Link-Template: <http://example.com?meta={+uri}>; rel="describedby";
> type="application/xrd+xml"; syntax="plain"; vocabulary="uri"; scheme="mailto
> http"
>
> XRD:
>
>     <XRD>
>         <Link>
>             <Rel>describedby</Rel>
>             <MediaType>application/xrd+xml</MediaType>
>             <TemplateURI syntax="plain"
> vocabulary="uri">http://example.com?meta={uri}</TemplateURI>
>             <site-meta:scheme>mailto http</site-meta:scheme>
>         </Link>
>     </XRD>
>
> The 'plain' template syntax means simple substitution of {variable}s. If the
> variable name is prefixed with a '+', it must be percent-encoded prior to
> substitution. The 'uri' template vocabulary includes: uri, scheme,
> authority, domain, port, path, query, fragment, and username.
>
> Using the template, the consumer construct the D-URI from the R-URI.
>
>
> EHL
> Ps. The above syntax for /site-meta is the expected format in the next
> draft. This flow does not use the regular Link records in /site-meta as
> those are used for the entire site (an abstract concept) and not for
> individual resources. There is no such URI identifying the "site".
>
>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]