Peter Davis wrote:
> Sorry, brevity introduced ambiguity :-(
>> All I was pointing out, is that when an application is presented with a URI
> to 'do something with', the local context assists the application what to do
> next. In this case, we think the context is 'I need some identity services
> for this identifier'.
>> So it seems to me to make sense to have the client provide hints to the
> resource about which representation it would prefer (be it
> application/x-metaidentity-whatever or more simply text/rdf). If the
> resource has such a representation, that should be provided.
>
As I see it, in the early days most users will be interested geeks or
enthusiasts, which is who the HTML indirection trick is aimed at: they
already have a website of some kind, and can turn it into a YADIS
identity URL with no further programming or configuration.
As YADIS becomes more popular (assuming it does) a larger proportion of
all identities will be served by big providers who will be able to
respond to the Accept header and return the capabilities document directly.
LiveJournal is an example of this; since its journal views are dynamic
anyway, it's trivial to add a little extra logic in there to return a
capabilities document when the relevant hint is applied. The same will
likely be true for the dedicated identity providers at videntity,
myopenid and so on.
So the HTML indirection is just for the purpose of lowering the initial
barrier of entry for early adopters. It will become less important
moving forward. Consumers will still have to implement it, of course,
but the extra request overhead will become less frequent.