On 11/6/05, James M Snell <[EMAIL PROTECTED]> wrote: > > Luke Arno wrote: > > On 11/6/05, Thomas Broyer <[EMAIL PROTECTED]> wrote: > > > >>James M Snell wrote: > >> > >>>It definitely well could be done in an extension, but I think it's one > >>>of those things that hits well above the 80% mark that justifies > >>>inclusion in the spec. I think it would be a mistake not include the > >>>ability to do client-defined subsets within the core. > >> > >>As long as it is optional (and extensible), I've no objection. > >> > > By that logic we can heave all sorts of cruft into > > the core. I think you were right to suggest > > removing this. It is a nice extension but it is > > not at all needed for basic functionality. Anything > > we don't *need* should be put into extensions. > > This is what the 80/20 test is for. There has been enough of a > demonstrated need for client-defined subsets to justify it being in the > core. For *basic* functionality, no, it's not necessary, which is why I > would argue that it be made optional. Simplicity is not the only goal > we should be shooting for. >
I don't see it meeting 80/20. Maybe I am wrong. I think link following is more strait forward than URL construction and will serve most cases. (IRI. whatever. it will be URLs in real life) Even if you believe that 80% of implementations will need more than next following (which I don't), what percent of those will need more advanced search capabilities anyway? I would think that will be a good chunk. That means that list-templates only serve a middle ground between "follow next" and "use opensearch". - Luke
