Guido Casper <[EMAIL PROTECTED]> writes: > > Hunsberger, Peter wrote:
<snip/> > > > > I guess this depends on your definition of bottom up? The > way I was > > understanding you was more along the lines as an > incremental approach > > starting very small. Although JDBC has definitely been built > > incrementally it was never very minimal? Certainly, XQuery isn't > > anything minimal or incrementally improved (yet)... JDO, I > guess lies > > somewhere in between, but been a lot there since day one? > > I refer to bottom up primarily as a way to tackle a problem. JDO and > XQuery certainly build on the experiences made with SQL (and would be > doomed without it). > > Workflow (AFAICS) means many different things to many people. > I think we > must start small to really find out what kind of problems > people want to > solve with workflow (that's much harder by just discussing). > If people > have somthing to play with it might encourage further ideas > (driven by > their needs) and the whole thing (hopefully) starts evolving. > Otherwise > we might end up with the perfect solution to a problem that > most people > don't care about. Hmm, not sure. Work flow has been around well over 10 years and pretty well defined for all that time. It's missing a single language such as "SQL" but the various XML standards seem to have many basic concepts in common. You need a certain minimum set of functionality to have work flow in any real sense of the concept. Having said that, yes start small, build a basic API, but like I said previously, having done so, be prepared to throw it out (or at least go though a Woody to cforms like conversion)... <snip/> > > >>> > >>><expanded proposal> > >>> > >>>I believe what we need is some way to accommodate everyone, > >> > >>Here I think we disagree. > >><skip-elaboration/> > >>:-) > > > > > > Ok, I'll bite; why? Do you think Cocoon shouldn't meet the needs of > > it's entire user community? > > No, I think there is no way to accommodate everyone. The > harder you try > the more you might move away from that goal. > > Let me refer to the 80/20 point again and to this blog post (doing a > better job explaining than myself): > http://www.magpiebrain.com/archives/000198.html We're building a framework here. By definition it's got to do a lot more than 80%. XML without namespaces anyone? How about not being able to plug in Saxon? Sure, sitemap and flow don't make everyone completely happy, but I don't think anyone will argue that they do far more than 80%? In my book they are pretty close to 99%. I don't think I'd expect anything less from the Cocoon project for work flow either.... :-) Now, I'm not saying that you have to implement 99% of the work flow use cases any more than I expect Cocoon to come preloaded with 80% (or even 20%) of all the possible HTML forms in the world. What I am saying is that whatever is provided has to be flexible enough that the Cocoon community can implement 99% of their use cases themselves. <snip/>
