cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Berin Loritsch" <>
Subject Re: [RT] CallBack Style XML Handlers
Date Mon, 18 Mar 2002 15:02:17 GMT

----- Original Message -----
From: "Ivelin Ivanov" <>
To: <>
Sent: Sunday, March 17, 2002 12:10 PM
Subject: Re: [RT] CallBack Style XML Handlers

> Berin,
> I don't have high enough rank or knowledge of Cocoon to discuss this
> subject and should probably stay quiet, but since no one else seems to
> respond,
> I'll take the risk.
> 1) If you have been following the threads on HTML form binding and
> validation, you have noticed that one problem is how to branch the
> based on transformer output. Two proposed solutions emerged:
>   a) Implementing a Transformer with a "side-effect" of sticking in the
> sitemap a parameter which hints the result of the actual transformation
>   b) Implementing an XPath selector, which evaluates its test attribute
> against the result of the preceding transformation. I'm actually a bit
> surprised that threre isn't one implemented yet. After all the user's
> says: "The selector syntax is similar to the XSLT <xsl:test/> element". I
> know that the current Selector interface doesn't allow access to the SAX
> stream, but shouldn't that change?

No, The Selector is specific to the Sitemap.  It is used to select which
pipeline to use--not which XML fragment to use.  Besides, XSLT has its
own selector like syntax, so it would be an unnecessary duplication of

> It sounds to me that these are both somewhat in line with your proposed
> extension. If so can you elaborate a bit more on the subject with more
> implementation details and sample scenarios, say some multi page web

The main thing I am proposing is a way to compile an XML document, and
keep the "hooks" where dynamic content is inserted.  That way, we can have a
more efficient cache implementation, and a pipeline that truly
unnecessary transformations.

XSLT can work on fragments of XML as whole documents.

> 2) XSL is a pure functional language. As such it carries one of the main
> properties of these languages. There are no side effects. No matter how
> times a stylesheet is called with the same input document and parameters,
> the output will always be the same. This extends to the following:
> "Applying subsequent transformations over a document can be optimized to
> only process the parts of the document which changed". Many web pages are
> mostly static and they have a few dynamic sections which change from one
> display to the next.
> Cocoon's <aggregator> component allows for "manual" processing
> when the changes are known upfront and this allows for better caching of
> separate parts, which don't change together.
> Having working implementations of pure functional languages for over 10
> years now, I would expect that the "HotSpot" version of XSLT is not too
> from reality.

The XML Callback mechanism is a conceptually simple approach, and allows
the developer to do some really powerful things without unnecessary work.
lowers the load on the processor, and increases scalability.

> Is your callback mechanism a generalization of the <aggregator> component
> and a way to hint dynamic parts?
> If I understood correctly, if a callback returns the same document (same
> content) as it did once before, then eventually a "smart" XSLT processor
> (which cached earlier results) would still know that its (the callback's)
> portion of the document didn't change and shouldn't be re-processed.

That is pretty close.

Let's assume for instance that the XSP markup looks something like this:

<inbox xmlns:xsp=""

For each session, the user information is completely static.  The inbox
necessarily change that often either.  The compiled XML spec needs to mark
callback events in a special manner so that they are not lost in each
stage.  The output can be something like this:

  <h1><callback:event name="mycom:user"/></h1>
       <callback:event name="mycom:inbox"/>

The callback mechanism will resolve the resource name to the proper XSP
Now, the cache is already set with this information available, at least for
the user

When the request comes for the inbox, the resolver makes a quick resolution
and the
final results come out:

  <h1>Berin Loritsch</h1>
       <td>First Item to work on</td>

To unsubscribe, e-mail:
For additional commands, email:

View raw message