forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Tessner <>
Subject Re: SVG from skinconf issues
Date Fri, 04 Jun 2004 17:22:56 GMT
On Fri, 2004-06-04 at 09:38, Nicola Ken Barozzi wrote:

> > Will look over your ideas below.  My initial thought was creating
> > something for the skinconf similiar to how "site:" and "ext:" links are
> > handled via the LinkRewriter but not sure how feasible that would be or
> > what the impact on processing would be.  This transformer could work on
> > elements in a "skinconf:" (polluting :) namespace.  This would allow the
> > skinconf.xml to be more free-form as well, similiar to site.xml.
> Why can't it be freeform now? We use xpath in the aggregated doc.

True ...

> Recap:
> 1 - to get the skinconf values from the *skins* we aggregate
> 2 - to get the skinconf values from svg we have come to the conclusion 
> that the best way is to use an extra namespace and inject the values
> You are basically saying: why not simply use case 2 for all and even 
> make that into a special transformer?
> The problem is that these values are to be given the xsl, not the 
> document itself, so to make this equipollent we should make an xsl 
> extension, not an xml extension (namespaces).

What about transforming the XSL before using it?  Afterall, XSL is just
XML and cocoon would cache the result of that transformation ... :)

We should just be able to use something like:

        <map:transform src="cocoon:/skinconf-document2fo.xsl"/>

or in effect, run the XSL through a "skinconf" transformer (or somehow
generate an XSL from the skinconf.xml which could then be used against
SVG, XML docs and XSL)

The "skinconf-*.xsl" could be resources that either:

     1. Run the requested XSL through some sort of skinconf.xsl
        generated from skinconf.xml or
     2. Run the requested XSL through a "SkinconfTransformer".

Whatever is used could be used as an equi-pollutant manner for SVGs,
PDFs, or whatever other resources we may have that require skin


> I guess that the best bet is to keep on using namespaced values for the 
> documents and aggregation for the skins.

It'd be nice to have one method for handling both, since fundamentally,
it is all just XML.

Rick Tessner <>

View raw message