Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (hermes.apache.org: domain of gianugo@gmail.com designates
 64.233.184.199 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references;
        b=ktI6yP2P3T7dW9/LoTXSwRA01Um5pkrvaR6+7R73yB8QJ2v5tt5RaItKH43i+3lCKvsN0lQ3vZD40w2MHK+SQC0zNuLr+Edrt+1KI2iLBSUVrmqlwYZ4K0eFx0PUkKxLdp4nXEAZEBacUXim0wLy/Odcorub5ODm4hsljUOr8Rw=
Message-ID: <7557e99f050412060932823d4b@mail.gmail.com>
Date: Tue, 12 Apr 2005 15:09:05 +0200
From: Gianugo Rabellino <gianugo@gmail.com>
Reply-To: Gianugo Rabellino <gianugo@gmail.com>
To: dev@cocoon.apache.org
Subject: Re: Manually specifying a mounted sub sitemap's context
In-Reply-To: <425A9B51.9080203@apache.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
References: 
 <OF2127453A.AFCAF820-ONC1256FDE.006334D8-C1256FDE.0065D2FA@kuhnle.net>
	 <42593904.3070905@apache.org> <425A4832.5080707@apache.org>
	 <425A9B51.9080203@apache.org>

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.

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/)