On Apr 11, 2005 5:44 PM, Stefano Mazzocchi <[EMAIL PROTECTED]> wrote: > I mean, look at you: sitemap via webdav? via JCR170? what's next? SOAP? > what about describing the sitemap in LDAP directly, you could use > netinfo to edit it! hmmm, no, wait, what about sitemap via email? you > post the sitemap attached to an email to a mailing list and then the > last becomes the published one?
I'll take the offensive bit out, enjoy the ironic part and comment on the beef. I have always considered Cocoon as a *framework*. Frameworks are supposed to be horizontal foundations on which vertical layers can be built. With Cocoon you can build an e-commerce site, a CMS, a banking application or an XML middleware: to do so you use the "tools of the trade", sitemaps, pipelines and all the yadda-yadda. However, it very possible (and actually likely) that application's high-level business rules don't quite map to a Cocoon sitemap because either a) all they need is a small subset of the sitemap crop or b) the semantic equivalence is poor. Now, let me make you a concrete example: we are currently building an XML validation server which is supposed to be able to solve a few issues in the XML validation world for some B2B humpfko. Basically what we do is provide a sequence of validation steps where you can define an arbitrary set of schema, relaxng, schematron and the like. Every validation step is logged separately so that you can spot problems in the incoming flow, This is clearly a pipeline and Cocoon is - to me - the right tool for the job. However, this tool has to be administered day in day out from non Cocoon people, so compare this: <map:match type="xpath" pattern="/document/[EMAIL PROTECTED]'something']"> <map:generate type="stream"/> <map:transform type="msv" src="repo://some-schema.xsd"/> <map:transform type="mylogger"> <map:parameter name="level" value="warning"/> </map:transform> <map:transform type="schematron" src="repo://some-schematron.sch"/> <map:transform type="mylogger"> <map:parameter name="level" value="error"/> </map:transform> <map:serialize type="xml"/> </map:match> (and consider that this is hidden within the whole sitemap shabang, with components, resources, views and whatever) to this: <select xpath="/document/[EMAIL PROTECTED]'something']"> <validate src="repo://some-schema.xsd" log="warning"/> <validate src="repo://some-schematron.error" log="error"/> </select> If you were the one having to maintain some 500-ish of these statements, which format would you prefer? Heck, even I, notwhitstanding my Cocoon experience, would go for the second option - also considering how easy it would be to GUI-fy that format. Now, the second option can be clearly translated into an equivalent sitemap by means of an almost braindead xslt. And whether it can be disputed whether such a sitemap should be generated dynamically or in an offline way, I don't think that favoring a more domain-oriented vocabulary for a specific application can be FS. Not, for that matter, is FS willing to persist such configuration files in places other than the local filesystem (think clusters). I fail to see how webapp componentization and blocks are going to solve issues like this one. Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)