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 http://marc.theaimsgroup.com/?l=forrest-dev&m=110172138119333&w=2
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 (http://marc.theaimsgroup.com/?l=forrest-dev&m=110324061019177&w=2) 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="credits.title.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...
Hmmm...
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 divide?
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?
TIA
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------