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

Martin Atkins mart at degeneration.co.uk
Fri Feb 10 08:29:14 UTC 2006

Drummond Reed wrote:
> I'm actually sitting right next to Johannes at a conference today and was
> able to clarify this with him as well.
> Larry is correct, when an XRDS document contains a sequence of multiple XRD
> elements, it is always the final XRD element that describes the target
> resource (or, in YADIS terms, the target identity).
> The reason for a sequence, BTW, is that each XRD can represent a different
> subsegment of an XRI resolution path. For example, to resolve xri://@a*b*c,
> the resulting XRDS document from an XRI resolver would contain 3 XRDS, one
> from the @ authority for *a, one from the @a authority for @a*b, and one for
> the @a*b authority for @a*b*c.

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.


More information about the yadis mailing list