<html>
<body>
<font size=3>I really like the argument here. Rather than get into
a tangle of extensions and extensions of extensions, and extensions that
depend on more that one other item, the argument is to cut it off at a
single level. If things get more complex, start over with a new
extension, instead of going to a second level extension.<br><br>
Thus: Not O with extension A + A extended further
with C.<br>
Instead O extended
with D<br>
(D being A + C)<br><br>
Can we take the same argument presented below, and by a simple rote
change throughout, produce an equally compelling argument against first
level extensions? And an equally convincing proposal for what to do
about O with extension A?<br><br>
Cordially, Joaquin<br><br>
<br>
At 11:24 AM 4/5/2006, you wrote:<br>
<blockquote type=cite class=cite cite=""># But let's assume somebody now
extends A with C. Do we get this,<br>
# then?<br><br>
If you "extend A with C", you have a new extension, D, not
A+C.<br><br>
# Also note that this hierarchical scheme does not allow you to say<br>
# "Here is an extension C, and it depends on *both* A and
B".<br><br>
Agreed, but I don't expect (or want) anyone to "extend
extensions" in<br>
this way. I wouldn't create a plugin for a plugin for the same<br>
reason. If you want a new behavior, create a new extension.
Besides:<br>
at this level of granularity, I don't think the XRDS is the right<br>
place to specify these relationships *at all*. Whether my
extension<br>
depends on Bob's is something I should specify in my extension spec,<br>
and it's something that users of my extension should therefore know<br>
about. If you allow these dependencies to be *generally* specified
in<br>
the XRDS, I guarantee you that at some point they won't align with<br>
reality.<br><br>
I do agree that it's possible that someone will want to express
these<br>
dependencies at some point, but in the OpenID context I don't see it<br>
happening (well, not if you buy what I am saying about OpenID<br>
extensions). If and when LID needs to, <Service> elements for
LID can<br>
choose to do that however seems best for LID.<br><br>
# I think you feel uncomfortable just using the plain XRDS file<br>
# because you do not see how you can express "B cannot be used
without<br>
# A" (aka "B is an extension of A", or "B depends on
A").<br><br>
What is "plain XRDS file" (and, conversely, what is
non-"plain XRDS<br>
file")?<br><br>
# What about, then, extending XRDS to be able to express those<br>
# dependencies instead of creating a Service-specific extensions<br>
# mechanism?<br><br>
What sort of XRDS extension are you thinking about?<br><br>
-- <br>
Jonathan Daugherty<br>
JanRain, Inc.</font></blockquote></body>
</html>