cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject [RT] resource views, error handling, pipeline debugging
Date Wed, 28 Jun 2000 14:37:21 GMT
this collection of RT follows the precedent and tries to give a coherent
and abstract view of the problems associated with what the title lists,
things that we are currently missing in the pipeline or not properly

                        ------------------ o -------------

Pipeline revised

I recently came to the conclusion our pipe model must be enhanced. The
pipe currently passes SAX events. These are data events.

I want to add a metaevents pipeline, sort of a logging/tracing pipeline
where the components throw everything that is related to event
generation and not event payload.

Example of this are:

- pipeline tracing (knowing what's going on, XSLT messages, FOP page
generation output, pipeline timings, etc...)

- error reporting (xml non-wellformed, exception inside a component,
exception inside a server page)

So, every component is given access to the stream of events of the next
component, plus the orthogonal stream of pipeline metaevents. The
implementation of this metaevent stream is not semantic abstract like
SAX but its semantic specific (like any logging class).

Something like

  public interface PipelineLogger extends Generator {
     public void startPipeline();
     public void endPipeline();
     public void trace(Component origin, String message);
     public void error(Component origin, String message, Exception e);

This doesn't change the shape of the pipeline, but since PipelineLogger
extends Generator, it is possible to use the "tracing" results of a
pipeline, XML-ize them and feed them thru another pipeline for

This solves the issue of error handling with multiple user agents. The
pipeline as a whole becomes a generator for another pipeline.

Resource views

A "view" is a different way to look at a resource. In fact, the above
metapipeline is a different way to look at the resource generated by the

Another possible view is the load statistics for that resource.
Another possible view is the semantic model contained in the resource.
Another one is the xlink information.
And so on...

I'm sure there will be many others in the future.

The concept is clear: there are different "aspects" of the same resource
and we want to be able to concentrate on each one of them separately and
be able to request them independently. They are all part of the same

Views are the abstract equivalent of orthogonal projection. They are
sometimes called hyperslices (or "projections on hyperplanes").

A resource is almost always multi-dimensional. For example, XML adds
another dimension to UNICODE (markup), namespaces add infinite
dimensions to XML (independently nestable markup). But
multi-dimensionality come not only from its components, but must be
evaluated at runtime (like tracing, runtime errors or resource

HTTP includes a very procedural idea of "views" as "actions" but since
the http URI doesn't allow you to overrule the action (it might break
operation), it cannot be considered a real "view" (changing view of a
resource shouldn't break operation of that resource).

So, HTTP is not powerful enough to stand our multi-dimensional browsing
experience (maybe BXXP, I still have to find out), but we have to use
HTTP so we much "hack" around its limitations.


Well, with a particular request parameter


where all "cocoon:*" names are reserved for future use. It's an XML-ish
hack. but it works and it's easy to parse and easy to read and easy to
edit by hand.

If no "cocoon:view" request parameter is found, a request for the
"normal" view of the resource is asked.

NOTE: views should be distinguished from styles or format types. I could
ask the "semantic" view of a resource and receive a PDF document, a JPG
graph or an RDF list.

How does this fit into the sitemap?

that's the key question and I don't have a final answer... anyway...

A "view" is a semi-pipeline and doesn't have serialization capabilities
(this is due to the fact that "views" and "format" are independent


  <view type="linking">
   <generator ...>
   <filter ...>

while a "viewer" is a "serializer" on steroids

  <viewer type="linking">
   <filter ...>
   <filter ...>
   <serializer ...

So, for example a pipeline like

 g -> f1 -> f2 -> f3 -> s

can be refactored as

  [ g ] [ f1 , f2 , f3 , s ]
  [ g , f1 ] [ f2 , f3 , s ]
  [ g , f1 , f2 ] [ f3 , s ]
  [ g , f1 , f2 , f3 ] [ s ]

Sort of pipeline diagonalization.

Why this? well, mainly to reduce verbosity, the components of a view
might change, but the component of a viewer might not.

For example, for off-line capabilities, the "view" might be different
for each resource, while the "viewer" could be the same for all the

 <viewer type="xlink">
  <filter type="xslt" src="./xslt/remove_all_but_xlink.xsl"/>
  <serializer type="xml"/>

So, in the pipeline, you should be able to define viewers as declarative
"subpipelines" and introduce event deviation with <view> elements.

For example, for the sitemap,

 <map:match pattern="complex-semantics/*">
  <map:view type="semantic">
   <map:generate src="./complex-semantics/{1}"/>
  <map:filter src="./style/tohtml.xsl"/>
  <map:serialize type="html"/>

 <map:viewer type="semantic">
  <map:filter src="./stylesheet/rdf-izer.xsl"/>
  <map:filter src="./stylesheet/xlink-izer.xsl"/>
  <map:serializer type="xml"/>

then we have


will return the "hello" resource as HTML, while


will return the "hello" resource as XML page with xlink and RDF
information. (the example is stupid, please interpolate a little by

This pattern is mostly equivalent to called templates for XSLT.

Error handing and view switching

Views cannot only be controlled by the request parameters, but also by
the sitemap itself. If a fatal error occurs and the pipeline cannot
process it, the "normal" resource view is changed to the tracing one.

While it's easy to identify a "viewer" when you are calling a "view"
specifically (their "type" attributes are equal), how do you know which
"viewer" your tracing view is associated to?

NOTE: PipelineTracer is not exactly a "view" since it may include
serializers, so the <view> element cannot be used here.

The solution I find the best (but I'm not sure and I welcome your ideas
on this) is creating  <pipeline> containers for <matchers>, each with a
different "viewer" mapping for their PipelineTracer.

So the sitemap root becomes




 <pipeline viewer="xxx">

type vs. name

A small detail, but could create lots of confusion: we are using both
"type" and "name" attributes to indicate IDREFs, I think we should use
only one flavor. Which one?

Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<>                             Friedrich Nietzsche
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------

View raw message