cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: [RT] Cocoon web applications
Date Mon, 08 Oct 2001 16:30:05 GMT
Stefano Mazzocchi wrote:
> 
> As we are touching a *deep core* problem, we must be very formal and
> abstract and analyze all the implicit assumptions. So this is why I have
> to be picky on what you say above:
> 
> if you read again my previous statements and understand my terminology
> that indicates that a "schema" contains all the necessary information on
> how to mix different namespaces, you'll understand that you make an
> implicit assumption in your analysis: the topological space defined by
> input and output namespaces are translated but never rotated.

This is not always the case.  For instance, Stylebook schema does not
"allow" you to mix arbitrary schemas inside of it--however in my example
that is temporarily the case.  The transformers convert it into the
proper schema.  Many times, Schema also allows you to embed an *any*
element (any schema, any markup after that point).

> This far from being trivial to understand so let me expand over your
> example updating the notation in a more readable (at least to me) form:
> 
>             g[doc][loc][schem] ->
>  [*][schem]t1[doc][loc] ->
>    [*][loc]t2[doc] ->
>       [doc]t3[xhtml] ->
> 
> which indicates that
> 
>  t1 transforms [schem] to [doc][loc] and everything else is copied over
>  t2 transforms [loc] to [doc] and everything else is copied over
>  t3 transforms [doc] to [xhtml]

The transformation process that I was attempting to point out was that
Cocoon knows that the Generator outputs [doc][loc][schem].  It knows
that t1 will take anything and transform the initial [schem] parts
to [doc] format.  Using simple logic, Cocoon knows now that the output
from t1 is now [doc][loc].  Again for t2, it knows that it will take
anything and convert the [loc] schema to [doc] and pass everything else.
It also knows by simple logic that the only schema left at this point
is the [doc] schema.  This allows t3 to go through with confidence and
the only result of the chain is [xhtml] schema.

In other words, the tracking mechanism knows how to narrow the pipeline.
In order to accomplish this, the schema declaration must be declarative
instead of reactive.  In other words, the sitemap must declare what the
pipeline components are expected to output and expected to accept.  That
way the pipeline optimization can happen without incurring a performance
cost at the beginning.

> but this is far from being a general enough notation, because it
> presumes that stylesheets work on namespaces orthogonally and don't mix
> them.
> 
> While I agree this is a "good way" to design modular stylesheets, it's
> not general enough, in fact it fails to describe a stylesheet that does:
> 
>  <xsl:template match="loc:element/doc:element">
>   ...
>  </xsl:template>
> 
> therefore assumes that the [doc] and [loc] namespaces are intermixed and
> in a well defined order.

Internal to a Cocoon webapp, this can and should be enforced.  The external
interfaces need to be robust enough with well defined schemas.

> Yes, it's very similar to what I was thinking, but this should NOT, IMO,
> happen at sitemap level, but at pipeline assembly level, thus when
> authoring and creating the webapp thru component composition.

Maybe not, but the interfaces must be well documented to provide the sitemap
and tools necessary for the resource.

> Such authoting tool might well be a GUI version of Cocoon itself or
> something else that connects to Cocoon for the deployment, I don't know,
> but all this looking-up and discoveries should not happen on a live
> site, IMO.

Exactly.  GUI tools require and encourage a good set of meta data to
allow both validation, and information to the user.

> > IOW, Root registers [doc] and [loc] with Stocking.  Stocking configures
> > itself so that it does not transform the [loc] schema--assuming that the
> > parent knows how to handle it.  However, because the Root did not state
> > that it could handle [schem] schema, Stocking applies the transformation
> > for that.
> 
> I get the feeling that too much happens behind my back. I'd like to be
> able to compose my pipelines in such an easy way, but I'd also would
> like to be able to modify my sitemaps by hand when required (WYSIWIG has
> drowbacks and we all know that very well, don't we?).
> 
> Also, how does this handle conflicts? what if there are two different
> instances of a transformer that performs the same behavior [for example,
> two stylesheets one fancy for nice graphics and one simple for text-like
> browsers]? how should I choose between them?

Again, let me give another example:

<map:match pattern="**.html">
  <map:generate source="xdocs/{1}.xml"/>
  <map:transform source="stylesheets/schem2doc.xsl"/>
  <map:transform source="stylesheets/loc2doc.xsl"/>
  <map:transform source="stylesheets/doc2xhtml.xsl"/>
  <map:serialize/>
</map:match>

The pipeline is declared for multiple resources (a common occurance).  Not
every resource has [schem] or [loc] schemas.  For those resources, the
unneeded step is removed.  The transform processes are declared in the sitemap
as always.  Again, with augmenting the stages with declarative schema information,
we can show how other transformers can be substituted (in the GUI tool).

> Behavioral-only pipeline composition might lead to unwanted behavior and
> would be very hard to understand what's wrong, expecially the more
> namespaces and components are mixed and aggregated.

I am not advocating behavioral-only pipelines.  I am advocating declared
pipelines with behavioral optimization.  There is a key difference there.

> So, the best solution would be, IMO, to allow behavioral-driven
> discovery of components in a sitemap editor and behavioral validation at
> CWA deployment, while leaving the sitemap (or whatever comes next) as
> static and explicit as possible, even if its readability is reduced.
> 
> I believe the path for easier Cocoon use passes also by creating aid
> tools because, in fact, sometimes we are simply too powerful to simplify
> the semantics of our configurations without sacrificing some of that
> power.
> 
> This doesn't mean the sitemap is perfect and will never be touched, but,
> IMO,  it should not sacrifice explicitness for ease of use, at least at
> this level.

When we have a tool to do pipelines, we can make the sitemap information
painfully explicit.  Until then, there are going to be pipelines reacting
to an aggregation of URIs.

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


Mime
View raw message