On 10/26/05, James M Snell <[EMAIL PROTECTED]> wrote: > > Luke Arno wrote: > > >I assert that you are limiting innovation by placing this > >constraint on the APP. You *are* creating a constraint. > > > > > > > I am not placing any constraints on the APP. I am not creating > anything. I am not the one making a proposal. The constraint already > exists in the current version of the APP. I'm not even defending that > constraint! I'm ONLY asking for a justification as to why the *already > existing* constraint should be removed. >
We just see this differently, it seems. All constraints should have a reason to exist. If a constraint provides no value then it *should* be removed. > >You don't want language that *explicitly* forbids it. The > >approach you support unnecessarily constrains the > >capabilities of the protocol thus making an extension > >mechanism necessary and possibly very unwieldy. > > > > > > > Huh? It's impossible to add a particular constraint to a spec by NOT > adding that particular constraint to a spec. > Not "by NOT" but "while NOT". Certainly. By choosing a model or format that is a de facto barrier compared to a less restrictive alternative. > For instance, the core Atom spec does not say anything allowing or > forbidding feed metadata expiration. Does that mean that there is a > constraint in the Atom format limiting my ability to add expiration > semantics? Hardly. > What alternative is there that would enable this without an extension or explicit language in the spec to enable it. If you can think of one then we should go for that but I don't see it. That is a very poor analogy for this reason. > I'm not arguing against nested collections. I'm saying that there is no > demonstrated need for them to be in the core spec. You seem to be > arguing that there is no demonstrated need to not have them in the core > spec and thus we should allow them. There are lots of potentially > interesting features we could add to the core that no one has > demonstrated a need to not have, should we go ahead and bake those into > the core as well? Or should we require folks that want to introduce new > features to justify why those new features deserve being in the core? > By choosing a format that does not prevent hierarchies we are not "baking in a new feature" but choosing not to impose a restriction. Introspection is a feature we are including one way or the other, no? *How* we define that format will either (explicitly or implicitly) prevent hierarchical arrangement, as the current approach does or (explicitly or implicitly) allow it, as my approach does. > >>It is absurd to propose and argue for a solution to a specific technical > >>solution to a problem that has not yet been demonstrated to exist. > >>That's a Bad Spec Writing Fallacy. What I am asking for is a use case > >>that demonstrates why your specific proposed technical solution is > >>better than what has already been put on the table. > >> > >> > >> > > > >Visible data. > >Principle of least invention. > >Layered semantics. > >Maintain fewer documents. > >Learn less new syntax. > >Fewest possible constraints. > > > >My proposal solves the problem of needing introspection. > > > > > > > I'm all for all the things you list but that doesn't answer the question > about whether or not nested collections should be baked into the core > protocol. These things can be accomplished without baking nested > collections into the core. Nested collections are orthogonal to the > need for introspection. Talk to me right now about nested collections, > NOT the what you perceive the benefits are of using microformats for > introspection. > I am not arguing *for* nesting collections. I am arguing *against* needlessly preventing them. Look. We are to define a format for introspection. Should that format prevent nesting or not. The question is not to bake or not to bake. It is to add restriction (implicit or explicit) or not. You not arguing against nested collections and I am not arguing for them. I just see no reason to prevent them when there allowance is zero cost for all practical purposes. Talk to me about why you want a more limited format. If you don't then maybe we don't disagree after all. > >Limitations need reasons. You propose more limitation. > >What is *your* justification for the additional limits? > > > > > > > I'm not proposing any limits. I'm not arguing in favor of the existing > workspace stuff. I'm not proposing anything at this point. I'm asking > you to explain why an existing limitation should be lifted in order to > allow for a new feature that you seem to think is necessary to support > in the core atom protocol. New features DO need reasons. Just saying > that "the fewer the limitations, the better" is not adequate as that is > obviously not always the case. > When is a restriction without a purpose beneficial? How can you foresee that it will not be detrimental to some future innovation? The fewer limitations the better, *all else being equal.* I am not arguing for a feature. I am arguing that its prevention serves no purpose. Are you honestly saying that there is nothing wrong with pointless restrictions?!? > >It should not use a more constrained approach that > >creates a barrier to hierarchical introspection for no > >reason. (It may not forbid it but it is discouraged > >without cause by your preferred approach.) > > > > > > > Sorry, not disallowing something does not equal "discouragement". I'm > not arguing for a more constrained approach. If I said "collections > SHOULD NOT be nested", that would indicate discouragement, but I am not > saying that. > The restriction is de facto. If you are not against a format that does not prevent nesting then, do you have any other objections to my proposed format? If not then can I count on a >=0 from you? > >You say you don't want to forbid it but you seem to > >want to stick with a format that makes it impossible > >via the core. Which is it? > > > > > > > When have I argued in favor of the existing stuff? When have I implied > that the existing stuff is adequate? If anything, my statements against > language forbidding nested collections should be a pretty clear > indicator that the existing stuff is not adequate. > Ok, then we are arguing about nothing at all. Do you have any other concerns about my proposal? If you do not feel the existing format is adequate then what are your thoughts on my proposed format. (BTW it does need lots of improvement. I am working on a new Pace and would sincerely love feedback.) > >If you do agree then do you refute that my proposal is > >less constraining? (Plus the copious fringe benefits I > >enumerated above.) > > > > > > > Fewer constraints on the protocol mean my application has to do more > work to interoperate with as many implementations as possible. Less > constraining does not necessarily mean "better". > If a particular constraint can be shown to improve interop then I am all for it. All else being equal, however, less constraints are better. If a constraint creates value I am all for it. - Luke
