cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vadim Gritsenko" <vadim.gritse...@verizon.net>
Subject RE: XInclude Transformer vs CInlude Transformer
Date Mon, 10 Jun 2002 18:03:29 GMT
> From: Ivelin Ivanov [mailto:ivelin@apache.org]
> 
> Vadim Gritsenko wrote:
> >>From: Mattam [mailto:mattam@netcourrier.com]
> >>
> >>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.
> >
> >
> > That's not right; XInclude also works with cocoon: protocol, they
both
> > use Cocoon's resolver.
> >
> > IIRC, the reason of CInclude existence is completely different: if
you
> > remove CInclude, it will be more complicated to serve documents with
> > inclusions and with tags in xinclude namespace. Right now, this is
not
> > an issue: create document with xinclude *and* cinclude tags, process
it
> > through cinclude, and xinclude will remain intact, no sweat.
> 
> 
> Does this justify a separate code base though? Allowing the Xinclude
> component to act on a sitemap parameter specified namespace should do.

Carsten? Donald? Why we have two transformers?
:)

If xinclude gets caching ability (as CachingCIncludeTransformer does), I
say one transformer should suffice.

Vadim



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


Mime
View raw message