Hi Reinhard,
>>> [EMAIL PROTECTED] 08.06.2005 15:56 >>>
>Could be a Xalan bug. Could you try to run your transformation outside
of Cocoon
>using XSLTC? Then you know who (Cocoon or the XSLTC team) you can nag
to get the
>bug solved.
My own XSL-files are working with MSXML/XMLSpy and XALAN outside of
Cocoon.
It works also with XALAN inside Cocoon.
The pipeline contains a number of CInclude and Source write
transformations.
A simpler version of the same pipeline worked with XSLTC.
The question is:
Produces XSLTC side effects as mentioned in complex pipeline constructs
as
the following?
<map:match pattern="*.rssget">
<map:aggregate element="news">
<map:part src="cocoon:/{1}.rssdir" />
<map:part src="cocoon:/{1}.1" strip-root="true" />
</map:aggregate>
<map:transform src="rsscompare.xslt">
<map:parameter name="path" value="rss/{1}" />
</map:transform>
<map:transform type="cinclude" />
<map:transform src="time2time.xslt">
<map:parameter name="path" value="rss/{1}" />
</map:transform>
<map:transform type="cinclude" />
<map:transform src="rssstore.xslt">
<map:parameter name="path" value="rss/{1}" />
</map:transform>
<map:transform type="write-source" />
<map:serialize type="xml"/>
</map:match>
Inside the cincludes are calls like the following
cocoon:/xx/yy/idzz.date?serv=http://www.this-page.com
The Cocoon exceptions occured after rsscompare.xslt, the first
cinclude and after rssstore.xslt.
I remember a wiki stating to use XALAN instead of XSLTC under certain
conditions.
Thanks
Reinhard Haller
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
