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 Mon, 07 Jun 2004 20:35:08 GMT

Not to get tedious, I'll snip lots of stuff. But I've read it all with 
great intrest, and it has indeed given me more insight :-)

Rick Tessner wrote:

> On Sat, 2004-06-05 at 03:26, Nicola Ken Barozzi wrote:
...
>>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 ...

It's about making <fo:skinconf-value select=""/> tags work before the 
xslt. As you see, they are resolved before the xslt, thus giving the 
xslt a single tag, thus not making it possible for the xslt to perform 
xpath queries (like asking how many trail items are present).

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

Correct. Every content source should contain it.

...
>>Also, this could fix the problem we have with css files not being traversed.
...
> <snip what="example of the issue and use of Batik CSS parser"/>

Forget it :-)
I'm fixing it in another way, gonna commit tomorrow probably.

> Recap:
> 
> <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:>.
> </quote>

I've changed my mind, all because of your comments :-)

You are asking: "is skinconf content or presentation"?
Answer: it's metadata. Mostly, if not all, *presentation* metadata.

If I remove the page contents, it will not work. If I remove the logo, 
it will still work. Hence, the logo is presentation.

Let me be clear: content is not the only thing that conveys information, 
as "how" something is said also affects the "what". Our task is to make 
sure that core of the information given is in the content, all that is 
*crucial* to be conveyed. We must keep presentation separate.

Now, let's get strict. If skinconf is presentation, it should *not* be 
accessible from content.

Let's see a real world example where we need to access skinconf from 
'content'... the logo. Wait, the logo is not content... so it should not 
be in the content dir, but in the presentation dir.

documentation
   /content                        - content
   /skins  <-- logo goes here      - presentation
   /resources                      - 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.

Let's see if we can fix this quick, else we'll just do this to release.

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

Skinconf is presentation. But remember that once the content enters 
Cocoon, it does not need to remain separate from presentation. In fact 
the aggregation is a blob that contains both data, metadata, style info, 
etc. At that point in processing, it's not theoretically a problem.

>      3. Move towards an <xi:include> style of use.  I personally do like
>         this one.

3) as described by me puts it in the content, so it's not an option.

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

'k

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

We have seen how the logo is presentation. Other example of needs?

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

This is already implemented, albeit in a strange way. See the *.css.xslt 
files in the krysalis-site skin to see what I mean.

I'm now going to focus on trying to access skinconf in a consistent 
manner in the skin files.

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

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


Mime
View raw message