OpenID 1.2 Extensions Proposal

[Jonathan Daugherty]

# But let's assume somebody now extends A with C. Do we get this,
# then?

If you "extend A with C", you have a new extension, D, not A+C.

# Also note that this hierarchical scheme does not allow you to say
# "Here is an extension C, and it depends on *both* A and B".

Agreed, but I don't expect (or want) anyone to "extend extensions" in
this way.  I wouldn't create a plugin for a plugin for the same
reason.  If you want a new behavior, create a new extension.  Besides:
at this level of granularity, I don't think the XRDS is the right
place to specify these relationships *at all*.  Whether my extension
depends on Bob's is something I should specify in my extension spec,
and it's something that users of my extension should therefore know
about.  If you allow these dependencies to be *generally* specified in
the XRDS, I guarantee you that at some point they won't align with
reality.

I do agree that it's possible that someone will want to express these
dependencies at some point, but in the OpenID context I don't see it
happening (well, not if you buy what I am saying about OpenID
extensions).  If and when LID needs to, <Service> elements for LID can
choose to do that however seems best for LID.

# I think you feel uncomfortable just using the plain XRDS file
# because you do not see how you can express "B cannot be used without
# A" (aka "B is an extension of A", or "B depends on A").

What is "plain XRDS file" (and, conversely, what is non-"plain XRDS
file")?

# What about, then, extending XRDS to be able to express those
# dependencies instead of creating a Service-specific extensions
# mechanism?

What sort of XRDS extension are you thinking about?

-- 
  Jonathan Daugherty
  JanRain, Inc.