forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <>
Subject Re: [RT] Per document skinconf (was Re: coloring table cells [from the user list])
Date Wed, 23 Feb 2005 17:32:18 GMT
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. 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:


and presentation data:


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"

is presentation data.

I think to further blur things in this way would be dangerous. 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.

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

Directory Structure

How does this affect the proposed directory structure in your RT?

You propose:

                ** all other content

This would become (arrows indicate changed/added lines):

-->	      content.xml
-->	      content.meta.xml
                ** all other content
-->		pdf-output.conf.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.

(At Burrokeet I am doing some extensive work on Meta-Data at present, I 
hope to be moving much of this into Forrest in 2-3 months, fortunately 
Nicola's RT memes seem to be infecting my work there too :-)).


View raw message