forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: [RT] Per document skinconf (was Re: coloring table cells [from the user list])
Date Thu, 24 Feb 2005 10:20:20 GMT
Ross Gardler wrote:
> Nicola Ken Barozzi wrote:
>> Ross Gardler wrote:
>> ...
>> I agree to the intent, and in fact I had done a similar proposal, 
>> although without considering the impact for the plugins.
>> Read this and tell me what you think, and how the two may fit.
>> [RT] Directory structure and configuration
> I remember this RT now, it seems that my RT includes many of the meme's 
> planted by you in your original - this is a good sign. 

Indeed! :-)

> Lets discuss...
> What is Meta-Data? What is Presentation Data?
> =============================================
> In re-reading your RT I discovered why I am not completely at ease with 
> the current skinconf.xml. We are confusing two types of data in the 
> skinconf.xml file. On the one hand there is true meta-data (data about 
> data), for example:
> <project-name>Forrest</project-name>
> and presentation data:
> <disable-pdf-link>false</disable-pdf-link>
> We have gotten away with this so far because we do not handle meta-data 
> separately. However, your RT and a post by Glen Tulikin 
> ( 
> start to look at how we can better handle true meta-data.
> Unfortunately, your RT further blurs the distinction between true 
> meta-data and presentation data, for example:
> <meta name="" content="Built with Forrest">
> is meta-data, but:
> <meta name="org.apache.forrest.disable-pdf-link"
>            content="true"/>
> is presentation data.
> I think to further blur things in this way would be dangerous. 

Hmmm, I don't understand why you think it's dangerous.... let's read on...

> I tried 
> to avoid this in my RT by ignoring the meta-data aspect. I was hoping to 
> sneak it through without the need to move meta-data nearer the data 
> raising its head. However, your RT has the intention of being "able to 
> define metadata nearer to the file that needs it".
> The problem is if we mix the two types of "meta" data "the file that 
> needs it" cannot be identified. I'll try to explain...


> Handling Meta Data and Presentation Data
> ----------------------------------------
> Meta-data is generated on a per file basis, with only a minority of 
> information coming from a central location. On the other hand, 
> presentation data has the majority of information coming from a central 
> location with only a minority being defined on a per file granularity.

Not necessarily. If a Forrest provider makes a site for multiple people, 
each would want it's own presentation metadata...

> This means that to be "able to define metadata nearer to the file that 
> needs it" we need to store the different types of data in different 
> locations. Meta-data needs to be closer to the file with an opportunity 
> to centrally define defaults (as per your RT) and presentation data 
> needs to be centralised with an opportunity to override locally to the 
> file (as per my RT).

Again, since there are both local and central locations, where is the 

> Directory Structure
> ===================
> How does this affect the proposed directory structure in your RT?
> You propose:
> my-project/
>          forrest.xml
>          documentation/
>               status.xml
>                ** all other content
>               FORREST-INF/
>                 skinconf.xml
>                 site.xml
>                 tabs.xml
> This would become (arrows indicate changed/added lines):
(inserted correct version)
> my-project/
>         forrest.xml
>         documentation/
>              status.xml
> -->          content.xml
> -->          content.meta.xml
>               ** all other content
>              FORREST-INF/
>                skinconf.xml
> -->            pdf-output.conf.xml
>                site.xml
>                tabs.xml
> -->            metadata.xml 
> Note that with the introduction of a meta-data plugin all the meta-data 
> files would be optional since the plugin would provide defaults. 
> Similarly the plugin conf.xml files are optional. So although this looks 
> like adding many new files, they are only present if actually needed by 
> a user.

I don't understand what the files you add contain.

I suppose that content.xml is a normal xml file, and content.meta.xml 
it's metadata. Why not insert the metadata in the file itself like I 
proposed? I prefer to keep faith to the 1 file -> one output rule.

Also, what is the relationship between skinconf.xml, pdf-output.conf.xml 
and metadata.xml?


Nicola Ken Barozzi         
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

View raw message