Namespaces in YADIS Capabilities Documents

[Michael Graves]

Josh Hoyt <josh <at> janrain.com> 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:
> 
>
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.

First, let me say that one of my (our) goals here is to leverage useful existing
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, as
much of my "changes" are really "simplifications" -- removal of things that are
extraneous, and more importantly, complicating and confusing for users who are
trying to configure, read and manage their YCD/XRD. I don't presume to tell XRI
to take anything out, however; I've read enough of it to understand how nicely
integrated it all is. 


I've looked at the PDF you linked here, thanks, and now I finally have a real
.xsd doc to work from. I've been working on this thing called the ID Sandbox
(http://www.idsandbox.com) which is a "workshop" for this stuff, and will host
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. It'll
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 of
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 to
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 the
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 to
monkey with it by hand. Forgetting a trailing "/" (or adding one when it doesn't
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 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. 

I have a project underway at the Sandbox that will show what I mean. Select your
 desired capabilities, add your parameters for your specific service
configuration, press the button, and presto! out comes a correctly configured,
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 the
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="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
> 
> 

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 auto-configuring
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 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. 

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.

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.

-Mike