On 10/26/05, James M Snell <[EMAIL PROTECTED]> wrote: > Luke, similar arguments were presented in favor of nesting Atom feeds > within other feeds. Note that we did not do that either. What I am > talking about is what belongs in the *core* of the Atom Protocol > Specification. Robert wants his XOXO service outline thing that supports > arbitrary nesting of collections included normatively in the spec as THE > way of doing introspection and yet neither of you have demonstrated that > arbitrary nesting of collections is a core requirement. If you and > Robert want to create an extension that defines how nesting can be > achieved, go for it. >
I have not advocated required support. My preferred introspection format simply does not *prevent* hierarchy. That is a nice straw man you have built there. - Luke > Luke Arno wrote: > > >On 10/26/05, James M Snell <[EMAIL PROTECTED]> wrote: > > > > > >>Luke Arno wrote: > >> > >> > >> > >>>What is the argument for forbidding "nesting"? - Luke > >>> > >>> > >>> > >>> > >>> > >>Simple: it's not needed. Now your turn: what is the argument for > >>allowing "nesting"? Give me a non-hypothetical use case that requires > >>arbitrary nesting of collections and demonstrate to me how the existing > >>workspace model (which I am not defending, btw) does not meet the need. > >> > >>Note: I'm not talking about format here. I'm talking about the > >>*model*. How this stuff is actually represented in XML is irrelevant at > >>this point in the conversation. > >> > >> > >> > > > >This is a protocol that is very close to the application layer > >so it is tough not to get caught up in thinking about this > >as if we were talking about the best one way to do it. > > > >I feel that we should create minimum restriction in order to > >allow for maximum future growth. Extensibility and room > >for innovation are worth supporting hierarchy (or "arbitrary > >nesting" as you have pejoratively coined it) which can > >really be ignored on client or server. > > > >I think it is a bad idea to restrict things for no reason. > >People may want to look at there blogs / subblogs / > >collections in a hierarchical way. The structure can be > >ignored by clients if they wish. It can be supported or > >not by the server without requiring that be represented > >in any explicit way. > > > >This does not interfere with interop so let it be done. > > > >HTTP did not evolve from a set of use cases to justify > >every constraint that was *not* placed on the protocol. > > > >Null Style. > > > >- Luke > > > > > > > >
