Yadis Conformance Testing

[Dan Lyke]

A general note. Johannes has forwarded some questions about the test to  
me, and I've answered some directly. The "why don't you like my YADIS  
URL?" questions so far seem to boil down to two issues:

1. XML namespaces. There'll be a version along shortly which warns when it  
finds a "Service", "URI" or "Type" element in a namespace that isn't the  
one associated with 'xri://$xrd*($v*2.0)', but as a general practice I'd  
suggest just using the template in the spec rather than trying to get too  
fancy with namespaces, if only to save some trouble for the poor soul who  
thinks they can get away with implementing a relying party parser with  
regular expressions.

2. Returning the YADIS document as a mime-type that isn't  
'application/xrds+xml' when 'appplication/xrds+xml' is included in the  
initial "Accept" headers. My interpretation of the spec is that it's okay  
to serve the YADIS document as a different MIME type if you use one of the  
redirection methods and offer that up from a separate URL (although users  
who find themselves unable to specify a proper MIME type for a served  
document should discuss this with their sysadmins, a sledgehammer should  
be unnecessary but is recommended), but sections 6.2.5 and 6.2.9 are  
pretty plain that if that initial URL serves up a YADIS document it had  
better be application/xrds+xml.

(Of course now I need to go double-check that we're not checking the MIME  
type when we do subsequent requests to a different URL, and we should  
still warn if we find a conflicting MIME type.)

This has also been an interesting exercise for me because normally when I  
implement this sort of code I use the spec as a rough guideline and the  
existing implementations as my final test. If I can tweak my code to  
handle input more flexibly, that's good. In this case I'm trying to make  
the spec the final arbiter, and as we find exceptions in other  
implementations build heuristics to try to inform people about why this  
bit of code doesn't like it rather than extracting the data where-ever we  
can.

And I've also no illusions that my reading of the spec and implementation  
in this code is the final arbiter, I've already discovered two pretty  
embarassing omissions (Josh pointing out the missing "x" in  
application/xrds+xml,  and the fact that you can have one *or more*  
<Type>s per <Service>). And if my first response to your concern seems a  
little boneheaded, press harder. It could be that I'm being boneheaded.

I now return to my usual 3d graphics programming...

Dan