Gianugo Rabellino wrote:
> On Apr 11, 2005 5:44 PM, Stefano Mazzocchi <stefano@apache.org> 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/[@type='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/[@type='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.

I wonder how long is going to take for somebody to introduce <if> in 
there. ;-)

-- 
Stefano.