cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <>
Subject RE: XInclude Transformer vs CInlude Transformer
Date Thu, 13 Jun 2002 11:16:49 GMT
Stefano Mazzocchi wrote:
> Mattam wrote:
> >
> > Ivelin Ivanov [Sun, 09 Jun 2002 11:22:07 -0500]:
> >
> > |
> > | Two almost identical transformers are confusing me.
> > | What is the difference between the two?
> > | Should one be deprecated?
> > |
> > | I'd vote for the one which implements the W3C XInclude spec closest.
> > | Maybe it should take the best of the other one.
> > |
> >
> > CInclude allows cocoon:/ protocol, and XInclude tends to be a
> strict implementation of the standard. Maybe keeping only
> XInclude while allowing the cocoon:/ protocol (with a switch?)
> would be the better.
> I agree, having both is highly confusing. Moreover, I think that we
> should *not* be using the XInclude namespace on the server side because
> we could get collisions in the future for browsers implementing XInclude
> on the client side.
In some cases this is true, but not in all. Imagine, fetching a distant
XML document containing xinclude commands. For processing it you need these
extra pieces of information, so you have to include the referenced documents
and therefore you need a xinclude transformer in some cases.

> For example, suppose you have something like this
>  <blah>
>   <include xmlns="" src=""/>
>   <include xmlns="" src=""/>
>  </blah>
> the first tag should *not* be processed by Cocoon, even by an
> 'including' transformer.
> So, IMO, the best long term solution would be:
>  1) deprecate both XIncludeTransformer and CIncludeTransformer
>  2) change CIncludeTransformer to IncludeTransformer
>  3) make IncludeTransformer work just on a cocoon-specific namespace
> what do you think?
Again, I think XIncludeTransformer makes sense.

And we still have the third include transformer, the session transformer
which use is more verbose but therefore more flexible. Example:

	<session:include xmlns:session="">

As you can see by this example, you can parameterize the connection (for
setting the HTTP method to POST) and you can simply add parameters (for
the user=xyz).

I admit that this is rather verbose, but it is very usefull, especially
the method and the simple handling of additional parameters is a *must

So I would suggest that we deprecate the cincludetransforer and use the
functionality for a new include transformer (not necessarily the syntax and
names, but the functionality).

What do you think?


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

View raw message