Marcus Crafter <[EMAIL PROTECTED]> > > On Wed, 2004-07-28 at 14:15, Carsten Ziegeler wrote: > > But let not implementation details (or technics) drive the > syntax. It > > is more important to have a good sitemap language than to > have a clean > > and small implementation. > > I agree too mate. > > Something that I'm wondering about is what the relationship > would be between flowscript and sitemap-script if we allowed > the sitemap to be scriptable. > > My first impression would be that the 2 would merge - the > temptation would be there for our users to write their > flowscript around their sitemap definition (good thing or bad thing?) > > The XML syntax prevents keeps flow and sitemaps separate - > perhaps its worth working out the relationship between both concepts? >
I was wondering about this also. Some may recall that over the years I've also wanted to implement a XSLT version of flow: an XSLT that spits out the current page in response to various xPath matches. Functionally this merges the sitemap with XSLT yet the two are driven from different declarations: a page production hierarchy, vs. a flow hierarchy. (While we're at it we should probably throw in a work flow hierarchy.) The interesting thing here is, you end up with hierarchies of intermeshed hierarchies. Now XML and XSLT may not be the perfect language for managing a graph but at least you can do it (at least for some restricted cases). I'm having a hard time seeing how one could do the same generalization with any non-declarative language? You'd basically have to end up allowing each processor (page production, presentation-flow, work-flow) to call each other but the opportunities for infinite loops and non-provable interactions would abound? I'm not saying don't do Groovy or whatever, but the value of XML isn't just in the direct usage of the tools (ie; using a parser within Cocoon). There is a lot of associated work going on around XML that one may eventually want to exploit in Cocoon. As others have said, one needs to step back and look at the overall objective: what do you want Cocoon to do when you feed it a request (either via http or CLI or whatever)? Figure out all the high level use cases and their interactions, step back, generalize and repeat. Personally, I end up with something more like RDF and ontology traversal than I do with scripting... I don't think many people could afford the hardware to do that in real-time for large scale web sites, so I come back to XML technologies as a reasonable compromise for the near term.
