extension not service - II

[Joaquin Miller]

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.

Thus: Not O with extension A   +   A extended further with C.
           Instead O extended with D
              (D being A + C)

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?

Cordially, Joaquin


At 11:24 AM 4/5/2006, you wrote:
># 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.danga.com/pipermail/yadis/attachments/20060405/255ba83f/attachment.htm