Namespaces in YADIS Capabilities Documents

[Josh Hoyt]

On 11/27/05, Michael Graves <groupmg at gmail.com> wrote:
> hand-editing of your YCD/XRD is not advised [...]
> If we really believe this is a framework to enable large numbers of users, I
> think we have to understand now that the XML format for the YCD/XRD should be as
> simple as possible, but no simpler, and in any case it's unreasonable to think
> that YADIS will see any level of broad adoption without "Wizards" and
> "Builders", and "Behind-the-scenes-your-ISP-did-it-for-you" configurators for
> YADIS users.

Agreed.

> I understand what you are saying about sharing namespaces, and I'm all for it
> principle - defining "sso" at "http://yadis.org/xmlns/sso" for example, but my
> instincts strongly suggest that for now, we try to travel light, and not take on
> the burden of defining "service suites", etc. This is exactly the kind of
> attractive feature that brings a spec, and the movement behind it, to  a
> grinding halt.

It doesn't have to be hard. If we agree to define a minimum namespace
that consists of things that we agree on, and leave out anything
contentious, we can make the common case easier (for the people who
have to create authoring tools, if for no one else). I think that
adding a namespace that specifies a username is an obvious, useful
extension, and I don't expect that if we use XRD, there will be any
objection to that.

I have no objection to allowing services that need parameters that we
can't agree on to create their own namespaces, and I don't want to
cause any delay in moving forward, but I think that we can come up
with a minimal useful set of common parameters, and that having those
parameters available will make interoperability easier. Adding a new
service type that needs parameters that another service type already
defines will not require designing a new namespace and will allow code
to be shared between services that use that same namespace.

> I propose that each sevice be declared "a world unto itself" for now, and that
> YADIS asserts that any "bindings", mapping LID and Liberty's SSO functions
> togehter as "SSO", be declared "out of scope" for YADIS. Relying parties will
> have to know what is or is not a qualifying service for it's SSO needs, for
> example. YADIS should not try to be the "service aggregator/organizer" at this
> point in its young life, IMHO.

I think that using the same vocabulary to talk about elements with the
same meaning is not mapping functions together. I also fear that
namespace fragmentation will make the XRD files appear to be more
complicated than they are. My instincts may be wrong here, but I just
have an automatic objection to introducing a standard where
<openid:delegate> and <typekey:username> both must be defined even
though they serve the same purpose.

> Thanks for the link, I'm on my way updating code to use the schema provided, and
> will report back with what I find out.

Thanks for your practical insights and feedback. I await your report.

Josh