Hello Wendell,
(It's really a long time since I heard of you the last time - must have been
on the MulberryTech XSL list.)
> Hi,
>
> I've been messing with Cocoon 2.1.7 for a few days now. I like it a great
> deal. Simple things do not have to be complicated.
>
> Because my application really benefits from the draft XSLT 2.0, I've got
> Saxon 8.3 wired in. It's doing very well. (Snappy!) But ... I've run into
> a
> discrepancy which I have to believe is a Cocoon thing.
>
> I'm calling the document() function very simply -- if a value $source-name
> is supposed to be a reference to an SVG file, I'm querying it to get the
> dimensions of the SVG (given as attributes on the document element) and
> putting them onto a temporary tree:
>
> <xsl:variable name="dimension-lookup">
> <d>
> <xsl:choose>
> <xsl:when test="ends-with($source-name,'.svg')">
> <xsl:attribute name="what">Hoo! got SVG!</xsl:attribute>
> <xsl:for-each select="document($source-name,/)/*">
> <xsl:copy-of select="@width | @height"/>
> </xsl:for-each>
> </xsl:when>
> ...
> </xsl:choose>
> </d>
> </xsl:variable>
>
> Outside Cocoon, this works -- when I copy this 'd' element to the output,
> having provided a $source-name='westminster.svg' I get
>
> <d width="872" height="184"/>
>
> ... which reflects, in fact, the correct values in westminster.svg.
>
> But when I run it inside Cocoon, I just get a plain <d/>.
>
> In my sitemap, in order to ensure I can read these SVGs, I have:
>
> <map:match pattern="**.svg">
> <map:generate src="{1}.svg"/>
> <map:serialize type="svgxml"/>
> </map:match>
>
> ... which appears to be sufficient to give me the SVG back when I provide
> it to Cocoon directly in my browser.
>
> Anyone have a clue as to what's going on? I figured this might be a FAQ,
> except I'm using the latest-and-greatest. Google gives me only hints like
> "using the document() function inside Cocoon isn't recommended".
The reason for the hint is a caching issue IIRC. document() should work in
principle.
>From your sitemap snippet I guess you think document() path is resolved
against sitemap, what's not done AFAIK. This might already be the reason for
the failure. You can switch to sitemap by using "cocoon:/" pseudo protocol.
Otherwise the path should be resolved in file system by default.
Furthermore there should be a log entry when document() fails. But I don't
know on which log level it logs.
Hope this helps,
Joerg
--
Sparen beginnt mit GMX DSL: http://www.gmx.net/de/go/dsl
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]