multiple URI elements per Service in XRDs

Josh Hoyt josh at
Thu Jan 19 20:57:17 UTC 2006

On 1/19/06, Martin Atkins <mart at> wrote:
> Kevin Turner wrote:
> > On Thu, 2006-01-19 at 10:48 -0800, Johannes Ernst wrote:
> >
> >>Yes, but will they truly be on the same service? It appears to me
> >>that if I have a choice of doing the same thing via HTTP and HTTPS,
> >>I'd have a preference which one should be used, and thus they would
> >>be in different service elements with different priority attributes?
> >
> >
> > XRD allows for priority attributes on the URI element as well as on the
> > Service element.  So I'd probably want to express that case as
> >
> >   <Service priority="10">
> >     <Type></Type>
> >     <URI priority="10"></URI>
> >     <URI priority="15"></URI>
> >     <openid:Delegate></openid:Delegate>
> >   </Service>
> >
> >
> >
> How is one to interpret the priorities in this case?
> Should an application first select a top-level service element based on
> priority and then select a URI from within it based on priority?
> Also, how does the above example differ from the following?
>    <Service priority="10">
>      <Type></Type>
>      <URI priority="10"></URI>
>      <openid:Delegate></openid:Delegate>
>    </Service>
>    <Service priority="15">
>      <Type></Type>
>      <URI priority="15"></URI>
>      <openid:Delegate></openid:Delegate>
>    </Service>
> ...or was this allowed purely as a document size optimization?

It's functionally the same, assuming that there are no other service
definitions inside that XRD. It does serve to make the document
smaller, but I think that it also serves to make the intent clearer to
a reader and make it easier to author.

If you have something like:

<Service priority="20">
  <URI priority="100">foo</URI>
  <URI priority="200">bar</URI>

<Service priority="21">
  <URI priority="10">baz</URI>
  <URI priority="11">quux</URI>

then the URI elements should have this order:

The algoritm for choosing is:
1. Walk the relevant service elements from lowest to highest value of
the priority attribute, followed by all elements with no priority set.

2. For each service in that order, walk the URI elements from lowest
to highest priority value.

In the case of a tie, try each of the tied elements in a random order.


More information about the yadis mailing list