Namespaces in YADIS Capabilities Documents

Drummond Reed drummond.reed at
Sun Nov 27 22:13:18 PST 2005

Michael, Josh, et al:

I've only just been able to catch up on the list tonight, and I've got
several stiff deadlines coming up this week, so I can't comment to the depth
I'd like to on this namespaces thread. Overall I agree with the general
conclusions I'm seeing:

1) Use standard XRD elements whenever possible because it just makes
processing/interoperability easier, but at the same time...

2)...don't be too averse to adding elements from other XML namespaces where
you really need them because that's why it's called XRD (and why its
carefully designed to be an easily extensible container).

A few quick points RE the XRD schema:

1) The XML schema in Working Draft 09 (link below) still has a few small
open issues. One of them is the inclusion of attributes ("id", "priority")
on certain elements. We're compiling these and plan to have them addressed
in Working Draft 10. Which brings me too...

2) ...anything that anyone in the YADIS community thinks needs to be
added/changed/deleted, please let us know soon, as we want to get out
Working Draft 10 by Dec 9. Just post it here to the list (preferably with a
subject line including "XRD feedback" or something similar); there are
enough XRI TC members on the list that we'll pick it up.


=Drummond (who will be on the road this week so email responses may be

-----Original Message-----
From: yadis-bounces at [mailto:yadis-bounces at]
On Behalf Of Michael Graves
Sent: Sunday, November 27, 2005 3:14 PM
To: yadis at
Subject: Re: Namespaces in YADIS Capabilities Documents

Josh Hoyt <josh <at>> writes:

> Hi, Michael,
> I have some feedback about your proposed changes to the service
> discovery document. The XML format for the service discovery document
> that we are considering is the XRD format as defined by:
> I'd like to refer to it as XRD. I think it would be unwise to use a
> format that is similar to but not the same as XRD. That is, if we use
> a non-XRD format, it should be totally independent of XRD to avoid
> confusion. This means that if we want to change the format, we need to
> try to get those changes adopted by the OASIS group that is defining
> XRD.

First, let me say that one of my (our) goals here is to leverage useful
technologies, and even more importantly, do what we can to get the XRI/XDI
community moving in the same direction with us.

I'm torn between the urge to spin something up to prove out the idea in
prototyping fashion, and the need to coordinate with you and Drummond, et al
about possible getting some changes pushed back into XRI.

I haven't really thought too much about concrete proposals for the XRI team,
much of my "changes" are really "simplifications" -- removal of things that
extraneous, and more importantly, complicating and confusing for users who
trying to configure, read and manage their YCD/XRD. I don't presume to tell
to take anything out, however; I've read enough of it to understand how
integrated it all is. 

I've looked at the PDF you linked here, thanks, and now I finally have a
.xsd doc to work from. I've been working on this thing called the ID Sandbox
( which is a "workshop" for this stuff, and will
code that actually implements many of the things we're discussing here. 

I will take the XML schema provided and rework my code to conform to it.
be a couple days, but I'll post back with some links when I'm done that will
show the schema in action. At that point, we should have a much better view
how this will shake out.

> XRD specifies the use of namespaced elements for arbitrary service
> elements. So far, so good. I see a couple of drawbacks to the XRD
> namespace approach:
> 1. Namespaces make ad-hoc parsing much more difficult, since it's
> impossible to know what tags are allowed in advance.
> 2. Namespaces make the document structure more complex, and thus
> harder for a human author to create.
> These arguments are weak, since an XML parser will be available in the
> vast majority of circumstances, and I imagine, especially if an XML
> format is used, it will be rare to author these documents without some
> kind of tool.

Absolutely agree here. I've been cranking on this for several weeks now, and
have this to report: hand-editing of your YCD/XRD is not advised. It's great
look at it for debugging, etc. but generally, if YADIS is going to succeed,
there will need to be tools and network services that "build" and "validate"
your YCD for you. 

This is an important observation for me, as I've been hoping to maxmimize
capabilities for the "one person with notepad and a hosted folder" scenario.
Unfortunately, no matter how simple we make the YCD/XRD, it's a risky thing
monkey with it by hand. Forgetting a trailing "/" (or adding one when it
belong) is all it takes to break your configuration.

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
that YADIS will see any level of broad adoption without "Wizards" and
"Builders", and "Behind-the-scenes-your-ISP-did-it-for-you" configurators
YADIS users. 

I have a project underway at the Sandbox that will show what I mean. Select
 desired capabilities, add your parameters for your specific service
configuration, press the button, and presto! out comes a correctly
pre-validated YCD/XRD that you can download, cross-load, or just stare at
happily for a time.
> I think that using the namespace to identify the service type confuses
> intent. It's clear that the value of a <Type> tag indicates the type
> of service, but it is not clear that the namespace of the Service tag
> defines the type of service. Also, the <Type> tag exists, so not using
> it would be even more confusing. Explicit is better than implicit. -1
> on using the xml namespace as the service type.

+1 on that. I retract the suggestion. In many cases, the <Type> URI will be
same as the namespace for the <Service>, but by coincidence, not design.
> The namespace drawbacks could be mitigated if we rely as heavily as
> possible on existing namespaces, rather than defining a new namespace
> for each service type. For example, the delegate field in OpenID is
> really just a special case of specifying a username for the service.
> If there was a vocabulary defined for specifying a username for a
> service, then both OpenID and e.g. TypeKey could use the same kind of
> tag in its service definition.
> <xrds:xrds
>     xmlns="xri://$xrd*($v*2.0)"
>     xmlns:xrds="xri://$xrds"
>     xmlns:sso=""
> >
>   <Service>
>     <Type></Type>
>     <URI></URI>
>     <sso:username></sso:username>
>   </Service>
>   <Service>
>     <Type></Type>
>     <URI></URI>
>     <sso:username>someone</sso:username>
>   </Service>
> </xrds:xrds>
> I think it would be a good idea to try to enumerate as many services
> as possible that will be used with this discovery scheme and try to
> find the common parameter types so that a standard set of parameters
> can be blessed.
> This is all assuming, of course, that XRD is the format on which
> consensus converges. It seems like it's a pretty good fit,
> feature-wise, but it comes with a lot of baggage. There are a lot of
> tags that are in there for XRI resolution that only serve to confuse
> when the format is used for the purpose of service discovery.
> Josh

If we understand that for YADIS to succeed, a lot of the complexity of the
YCD/XRD has to be abstracted from average users with tools and
services, I think that your concerns here, which I share, are diminished. 

I understand what you are saying about sharing namespaces, and I'm all for
principle - defining "sso" at "" for example, but
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. 

I propose that each sevice be declared "a world unto itself" for now, and
YADIS asserts that any "bindings", mapping LID and Liberty's SSO functions
togehter as "SSO", be declared "out of scope" for YADIS. Relying parties
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
point in its young life, IMHO.

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


More information about the yadis mailing list