Namespaces in YADIS Capabilities Documents

[Josh Hoyt]

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:

http://www.oasis-open.org/committees/download.php/15310/xri-resolution-V2.0-wd-09.pdf

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.

On 11/24/05, Michael Graves <groupmg at gmail.com> wrote:
> Since every <Service> declares a unique and defining URI, (via the <Type> tag),
> everything else within the <Service> tag is capability-specific. That means each
> service will have (potentially) it's own "vocabulary" of configuring info, and
> the tags used from one <Service> can and will clash with tags from a completely
> different <Service>.
>
> Using namespaces solved the problem for me. A namespace defined for a service is
> a built-in way to "scope" the child elements in such a way that they are quickly
> and reliably found. I now can use XPath on my YDCs to quickly extract all the
> "oi:server" elements, and they won't be confused with non OpenID <xyz:server> or
> <server> tags, as I'm telling XPath to only looking for <oi:server> elements
> within the appropriate namespace.

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.

> So, think about namespaces for the YDC, and also this: if a <Service> tag has a
> URI (the <Type> tag), isn't the capability URI a *de facto* namespace? If so,
> shouldn't we consider moving the <Type> tag into an XML namespace declaration:

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.

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="http://yadis.org/xmlns/sso"
>
  <Service>
    <Type>http://openid.net/protocols/OpenID</Type>
    <URI>http://myopenid.com/server</URI>
    <sso:username>http://josh.myopenid.com/</sso:username>
  </Service>
  <Service>
    <Type>http://typekey.com/protocols/TypeKey</Type>
    <URI>http://typekey.com/</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