Yadis Spec .9 Change Proposal: Section 7.3.1 clarify multiple XRD

[Drummond Reed]

One factor that may mitigate this risk somewhat is that I see few reasons in
a YADIS context for the provider of an XRDS document to provide more than
one XRD element. The multi-XRD capability is intended for XRI client
resolvers and proxy resolvers who need to provide the results of a
resolution request for a delegated (multi-authority) XRI. While this
multi-XRD capability may also have uses in other potential resource
description or service discovery scenarios, in the typical YADIS scenario
the XRDS document will just be self-describing and thus not need to contain
more than one XRD element.

=Drummond 

-----Original Message-----
From: yadis-bounces at lists.danga.com [mailto:yadis-bounces at lists.danga.com]
On Behalf Of Larry Drebes
Sent: Friday, February 10, 2006 8:47 AM
To: yadis at lists.danga.com
Subject: Re: Yadis Spec .9 Change Proposal: Section 7.3.1 clarify multiple
XRD


I hope you are wrong :).   I suspect that the early use of YADIS will be 
based around several common libraries and not one-off implementations.   
This flaw is very easy to test for, and if broken, it should be easy to fix.
larry-

Martin Atkins wrote:
> Unfortunately, this is one of those things that relying parties are
> going to get wrong. I guarantee it!
>
> Previous experience shows that there are two kinds of "wrong" when it
> comes to implementing specs:
> * You got it wrong so it doesn't work at all.
> * You got it wrong so it works most of the time except in some funny
> corner-cases and all of the spec authors are now scowling at you.
>
> This is the latter. Implementors are (by and large) lazy. They'll
> implement the bare minimum to make it look like it works. Most YADIS
> resource descriptors are going to have only one XRD segment.
> Implementors will probably use XPath like /XRDS/XRD/Service which will,
> of course, match the service elements in *all* XRD segments.
>
> So while it's obvious the YADIS spec has to take a definite position on
> this subject, everyone should be prepared for the fact that almost every
> relying party implementation is going to get this wrong and consider
> what the implications of this are.
>
> Cheers,
> -Martin
>
>