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 Mon, 07 Jun 2004 16:14:04 GMT
On Sat, 2004-06-05 at 03:26, Nicola Ken Barozzi wrote:
> Rick Tessner wrote:

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

Hmmmm ... I don't think I'm really clear on this distinction in this
case.  Skinconf is content for the skin (ie. information that can change
the look of the skin via the use of css and xslt).

Skinconf is part of the transformation.  It is not part of the xdocs

Or have I missed something fundamental (always a possibility :)?

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

I'll have to go search the archives to see what that proposal was ...

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

The aggregated skinconf works, but it does get a bit cumbersome when we
need those values in various places.

If we do go this way, we'd need to use aggregate whenever we transform
SVGs, the creation of PDFs (currently still require document()'ing
skinconf), etc.

The PDF one I've looked at a couple of times and doesn't seem
straightforward (again, I may be missing something simple :).

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

I'm still struggling with this.  I'm trying to figure out what skinconf
really is.  Is it content?  Or are they parameters used to configure the
skin?  Logos I'd count as content.  Menu placement and depth I'd count
as 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:>.

Yes.  And sometimes, we need to add skinconf to the presentation
configuration layer.  (Menu depth, page size/width for PDF)

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

I like the idea of this.  No re-inventing the wheel with a skinconf

> Also, it's much mor verbose than:
>     <for:skinconf select="group"/>

Yes, same idea as the <xi:include> with a cleaner syntax.

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

Not clear on this issue.  Time to go read the archives. :)

<snip what="example of the issue and use of Batik CSS parser"/>


<quote who="Nicola">
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:>.

I'd like to add to this that we also, in effect, add skinconf to the
transformations.  This is currently done by aggregating the skinconf
with the content we wish to transform and then use this aggregated
skinconf from the XSL itself.

This does have the feel of mixing concerns.  However, the skinconf is
used by both the content and by the transformations.

Couple of options (my own choice would be #3 below).

     1. Quick and dirty for a 0.6 release.  We keep as is and remove the
        DOCTYPE declaration from skinconf so that where skinconf is
        document()'d, it'll work.  This will impact validating editors
        and we'd need to make that clear.
     2. Move towards using an aggregated skinconf everywhere.  This does
        have a feel of mixing concerns to me.  But that's only because
        I'm not clear in what camp the skinconf actually lies.  Is it
        content?  Is it content for the presentation layer?  Is it both?
     3. Move towards an <xi:include> style of use.  I personally do like
        this one.

As an end-user of Forrest, there are a couple of things I'd like to be
able to do and I guess that what has determined my choice for the above.

      * I'd like to be able to edit the skinconf and have it validated.
      * skinconf for content. There are times when I'd like to be able
        to get at the skinconf values and know that there is a
        guaranteed and consistent way of doing this (colour a background
        image generated out of SVG using skinconf colours, for example).
      * skinconf for transformation.  There are also times when I want
        to get skinconf values for my transformation sheets.  Generating
        CSS using colours defined in the skinconf springs to mind. 

Perhaps this would be the best way to approach this.  How do people see
the skinconf being used in real life and what would be the best approach
to accomodate that?

Rick Tessner <>

View raw message