forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <nicola...@apache.org>
Subject Re: SVG from skinconf issues
Date Sat, 05 Jun 2004 10:26:29 GMT
Rick Tessner wrote:
> On Fri, 2004-06-04 at 09:38, Nicola Ken Barozzi wrote:
> 
...
>>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 ... :)

True...

> 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".

This is an interesting proposal, but it seems to mix concerns to me.
Skinconf is content, while xsls are tramsformations.

If so, then why was the precedent proposal o transforming the content 
with added <fo> namespace not ok? Because in that case we get only part 
of the skinconf content, not all of it.

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

Since we aggregate, all output formats can and should use the aggregated 
skinconf.

>>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.

Yeah, but we must clearly divide content from presentation.

Trying to do another recap:

We need to be able to add skinconf to content. Sometimes we need all of 
it, sometimes we need just part of it. In the first case we aggregate, 
in the second case we inject values with <for:>.

Wait a sec, is there any reason why we should not use xinclude instead?

    <xi:include href="skinconf.xml#xpointer(/skinconfig/group)"
                parse="xml"/>

In fact there is an issue, that we should always use the internal 
skinconf, not the original one, so it would be:

    <xi:include href="cocoon://skinconf#xpointer(/skinconfig/group)"
                parse="xml"/>

Also, it's much mor verbose than:

    <for:skinconf select="group"/>

In any case, I am starting to believe that the for: system should be 
used also in the skins instead of the xslt used now where possible.

Also, this could fix the problem we have with css files not being traversed.

  <for:text>
     css file stuff..
     ... <for:text src="put the link here"/>
     ... <for:skinconf select="group"/>

  </for:text>

Would give:

     css file stuff..
     ... put the link here
     ... group-value

It would not make all css files be automagically traversed, but if one 
uses this system it cam make them be traversed.

BTW, Batik has a CSS parser, if anyone wants to make an xml version of 
CSS...

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------


Mime
View raw message