Return-Path: 
 <cocoon-dev-return-22319-apmail-xml-cocoon-dev-archive=xml.apache.org@xml.apache.org>
Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org
Received: (qmail 68743 invoked by uid 500); 6 Feb 2002 12:22:35 -0000
Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:cocoon-dev-help@xml.apache.org>
list-unsubscribe: <mailto:cocoon-dev-unsubscribe@xml.apache.org>
list-post: <mailto:cocoon-dev@xml.apache.org>
Reply-To: cocoon-dev@xml.apache.org
Delivered-To: mailing list cocoon-dev@xml.apache.org
Received: (qmail 68731 invoked from network); 6 Feb 2002 12:22:34 -0000
Message-ID: <3C6119EE.4A7AC4BF@apache.org>
Date: Wed, 06 Feb 2002 12:56:30 +0100
From: Stefano Mazzocchi <stefano@apache.org>
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: [RT] Componentizing Cocoon Applications
References: <3C5D5893.7499B8DB@apache.org>
 <20020206062711.21FFE23D9B@dj.codeconsult.ch>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

Bertrand Delacretaz wrote:
> 
> On Sunday 03 February 2002 16:34, Stefano Mazzocchi wrote:
> >. . .
> > Let me make a sitemap example to see what I envision:
> >
> >  <match pattern="*.html>
> >   <generate src="docs/{1}.docbook"/>
> >   <transform src="[skin]://docbook/docbook2html.xslt"/>
> >   <serialize/>
> >  </match>
> >
> > where the absence of 'protocol' information indicates that the
> > component should look into its internal addressing space, while the
> > [***]: virtual protocol indicates that you should connect to the
> > implementation of the 'skin' role that you have choose at deployment
> > time.
> 
> If I understand right, the "skin" role would have a contract with
> Cocoon, but doesn't it need a contract with its XML input as well?
> 
> For example, a skin that expects docbook input will most probably not
> work with input conforming to myOwnFunnyDTD.
> 
> Wouldn't something like [skin/docbook] or [skin/myOwnFunnyDTD] be
> needed in defining these contracts (or subcontracts) more precisely?

Ok, first of all, it must be noted that a DTD is not longer capable of
explaining the validation of an XML Infoset, thus it cannot be used.
Example is that

 <a xmlns:a="a">
  <a:a/>
 </a>

is totally equivalent to 

 <a xmlns:b="a">
  <b:a/>
 </a>

but no DTD will be able to express this.

XMLSchema has the ability to change the Infoset. I personally consider
this dangerous for debugging since something comes out of the pipeline
and something else gets into the next stage... a hell to debug in case
the entity-resolution doesn't work (or even a performance nightmare
since the bottleneck might be hidden).

The only language left is RelaxNG (which I like best).

Now, your question (and Berin's, he's been proposing schema-based
contracts since a long time) becomes: is the 'webapp component' role a
solid enough contract, or we need a schema for that?

Ok, let's do some contract analysis on the above sample:

  <match pattern="*.html>
   <generate src="docs/{1}.docbook"/>
   <transform src="[skin]://docbook/docbook2html.xslt"/>
   <serialize/>
  </match>

[I will use this URI syntax as an example of its semantics, not as an
example syntax]

somewhere we have identified that 

 skin -> http://apache.org/cocoon/roles/skin/1.0

then we have installed

 mycoolskin.xcomp

which contains a 'descriptor.xml' that indicates that this webapp
component 
"implements" 'http://apache.org/cocoon/roles/skin/1.0'

So 'http://apache.org/cocoon/roles/skin/1.0' is the identifier of the
*contract* between the two interoperating entities.

                                       - o -

But is this contract?

Let's look at Java interfaces (which are the descriptions of the
contracts between Avalon components): they have a unique identifier (the
fully-qualified java classname) and they list a collection of methods
and/or final static values (almost like XML entities).

This contract indicates:

 1) what data the methods accept (if any)
 2) what data the methods return (if any)
 3) what exceptions are supposed to trigger (if any)

That's it.

The contract doesn't include any other information (might do so in the
future if Java generics are implemented properly, but I wouldn't count
on it) and Avalon is built upon the concept that a component 'behavior'
can be meaningfully described in a sufficiently solid way by a java
interface.

The success of Avalon seems to prove this fact true.

                                       - o -

Ok, let's keep on the parallel here: the 
'http://apache.org/cocoon/roles/skin/1.0' contract (well, the URI is the
indentifier, but it's a one2one relationship so I will call the
identifier 'the contract' since it's its name) is composed of:

 1) an internal addressing space

that's it.

Both you and Berin suggest that this might not be enough to indicate a
contract: I disagree, the above is sure enough. But I agree with you
guys that an addressing space might not be the best solution to describe
the relationships because is somewhat too general.

Let me explain: when we connect to 

   <transform src="[skin]://docbook/docbook2html.xslt"/>

this is nothing different from doing
 
  ((ObjectStore) store).store(key, object);

for Avalon components because 

 skin -> 'http://apache.org/cocoon/roles/skin/1.0'
 ObjectStore -> 'org.mystuff.components.ObjectStore'

and 

 docbook/docbook2html.xslt
 store(key,object)

represent the internal behaviors of that component.

The difference here is that the method 'store()' might be behaviorally
polymorphic, in the sense that different arguments might trigger
different behaviors... but from a behavior naming perspective, the above
two are totally equivalent.

                                       - o -

Ok, now let's try to come up with some schema-driven behavior and see
where this leads us to:

  <match pattern="*.html>
   <generate src="docs/{1}.docbook"/>
   <transform src="[skin]:[docbook]->[xhtml].[xslt]"/>
   <serialize/>
  </match>

where we have previously defined that 

 [skin] -> 'http://apache.org/cocoon/roles/skin/1.0'
 [docbook] -> 'http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd'
 [xhtml] -> 'http://www.w3.org/1999/xhtml'
 [xslt] -> 'http://www.w3.org/1999/XSL/Transform'

where
 
 [skin]:[docbook]->[xhtml].[xslt]

indicates

call the component that implements the 'skin' contract and ask it to
give me an 'xslt' stylesheet that is capable of transforming the markup
associated with the 'docbook' schema into the 'xhtml' schema.

But let's try a more complex example:

 <aggregate>
  <part src="cocoon:/slashdot/slashdot.xml" 
      element="slashdot" ns="http://foo.bar.com/slashdot"/>
  <part src="cocoon:/moreover/moreover.xml" 
      element="moreover" ns="http://foo.bar.com/moreover"/>
  <part src="cocoon://sidebar" element="sidebar"/>
  <part src="cocoon://body" element="body"/>
 </aggregate>
 <transform src="[news]:[rss]->[document].[xslt]"/>
 <transform src="[structure]:[layout]->[document].[xslt]"/>
 <transform src="[skin]:[document]->[fo].[xslt]"/>
 <serialize/>

is this any more solid than

 <transform src="[news]://adaptors/rss2document.xslt"/>
 <transform src="[structure]://adaptors/layout2document.xslt"/>
 <transform src="[skin]://stylesheets/document2fo.xsl"/>

???

Moreover, what if we want to choose between several 'flavors' of the
same contracts? One solution would be to do

 <transform src="[news]:[rss]->[document].[xslt]/no-abstract"/>
 <transform src="[structure]:[layout]->[document].[xslt]"/>
 <transform src="[skin]:[document]->[fo].[xslt]/A4/with-index"/>

which might require another addressing space (included probably into the
CWA deployment descriptor) to associate the above indications with the
right stylesheets.

The same functionality can be done eliminating this further address
space by taking the internal component file space and mapping it one2one
with the contract:

 <transform src="[news]://adaptors/rss2document/no-abstract.xslt"/>
 <transform src="[structure]://adaptors/layout2document.xslt"/>
 <transform src="[skin]://stylesheets/document2fo/A4/with-index.xsl"/>
 
Given that each file URI represents a behavioral contract (but I think I
outlined how changing the URI syntax doesn't change the need for such a
high number of contracts, given the small granularity of internal
component fragments due to the high degree of seperation of concerns), I
honestly fail to see the need for *yet another* mapping between schemas
and files included in the components.

As far as 'autoassembly' of pipelines, I do *NOT* think that this is
something that cocoon should be directly concerned about: automatic
pipeline assembly based on schema matching information (as Berin
proposed a while ago) are very dangerous since they can easily lead to
very unmaintanable sitemaps (in the sense that you know what they do,
but the next person that looks at them might not!)

Besides, schema-driven operation is inherently namespace unfriendly (as
you can taste from the aggregating example above) and I can't say I like
that.

Anyway, I'm wide open to suggestions and criticism.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org