Question: Yadis Service URIs in the OpenID Auth case

Martin Atkins mart at
Tue Aug 29 10:00:07 UTC 2006

Gabe Wachob wrote:
> An OpenID component will be the one
> interpreting the service blocks anyway... so shouldn't OpenID define the
> interpretation of these service blocks? 

On the other hand, it's nice to be able to have a generic parser library 
for XRDS where callers can just say:


...and get back an ordered list (ordered by priority) of all matching 

Not that I'm entirely convinced that this is opposing your suggestion. 
If the library avoids too much interpretation of the innards of the 
"Service" element then the "caller decides" approach can still work:

interface IYadisServiceEndpoint {
     double getPriority();
     string[] getURLs(); // A list of URLs ordered by priority
     XMLDOMElement[] getElements(string xmlns, string elemname);

Ignore the specifics for now; I know that that getElements method is 
ugly. The general principle is the important thing: the Yadis library 
(which might really be an XRI library; I've lost track of who owns what 
here) deals specifically with the XRI elements and exposes the non-XRI 
elements to a higher layer.

Then, if OpenID wants to define special handling for URLs in its service 
elements it should add its own property element instead of using the XRD 

<Service xmlns:openid="">

It can then define whatever semantics it wants on that element, 
regardless of what XRI resolution might have to say about its "URI" 
field. OpenID implementations using the above Yadis library will then 
just ignore the getURLs() method completely.

Of course, once I start down this road I start to wonder why XRI defines 
a global "URI" element at all, since the meaning of it will obviously be 
different for different service types. What was the thinking behind that?

More information about the yadis mailing list