>>> [EMAIL PROTECTED] 08.06.2005 21:01 >>> >Reinhard Haller wrote: >> How do you test this outside of Cocoon? >> >> <map:transform type="cinclude" /> > ><map:transform type="cinclude" label="stopHere"/> > >then add a view to your sitemap: > ><map:views> > <map:view name="stopHere" from-label="stopHere"> > <map:serialize type="xml"/> > </map:view> ></map:views> > >then call your pipeline http://......?cocoon-view=stopHere > >Save the result using your browser's "save page" function and use XSLTC in a >small Java programm outside of Cocoon. If the transformation fails you know it's > XSLTC's fault ant not Cocoon's.
The question behind was: How to test the Cocoon CInclude transformer outside of Cocoon? The CInclude target has the form: cocoon:/xx/yy/idzz.date?serv=http://www.this-page.com triggering a pipeline which reads content from the html page supplied as parameter, converts it to xhtml, searches the date string inside and parses the date string to produce a mime conforming date string to return to the caller. So what should I do to make an isolated test? >> >> My xsl files were all developed and tested outside of Cocoon before >> using them in a pipeline (using XMLSpy). > >I guess it's an XSLTC bug but how knows ... Let's summarize: 1) We have a pipeline, which works with the interpreting transformer Xalan 2) We have transformations and I suppose each of this transformations works executed as single step, regardless of the used transformer 3) The bug appeared after extending the pipeline serving the CInclude, i.e. instead of simply copying a string from a html-file I used Chaperon to parse the string and adjust the outputted string. Before this change there were no errors using XSLTC. So the pipeline which suffers the errors is basically unchanged. 4) The error occurs during the copy process. I used 3 different constructs to copy the (text) content: <xsl:copy-of select="*[name() = 'link']" /> <xsl:element name="link" namespace=""> <xsl:value-of select="link" /> </xsl:element> <xsl:template match="node()" mode="copy"> <xsl:choose> <xsl:when test="self::text()"> <xsl:copy-of select="." /> </xsl:when> <xsl:otherwise> <xsl:element name="{local-name()}"> <xsl:apply-templates select="@*|node()" mode="copy"/> </xsl:element> </xsl:otherwise> </xsl:choose> </xsl:template> In all 3 cases after the transform the link was changed from <link>http://xx.yy.com?par1=zz&par2=zz</link> to <link>http://xx.yy.com?par1=zz&par2=zz</link> The escaping should be a basic construct for all parsers/transformers. For me it looks more like a typical side effect, when multiple instances of the same program are nested. It happened more than once by tracking down the source of the error (shortening the pipeline commenting out transformations) that the error appeared on an other (earlier) stage of the pipeline. Are there any known problems with the nesting of pipelines? Is the XSLTC version bundled with Cocoon 2.1.7 the same as the released version (in Xalan 2.6) and how to use an actual version of XSLTC with Cocoon? >Have you had a look at Saxon8? It is reported to be very fast. Not until now, I've heared it isn't open source. Greetings Reinhard Haller --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
