forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <>
Subject Re: [RT] Forrest processing pipeline
Date Fri, 19 Nov 2004 00:18:12 GMT
Thorsten Scherler wrote:
> El lun, 15-11-2004 a las 10:11, Nicola Ken Barozzi escribió:
>>Step 2: Format Transformation (content)


>>(also automatic transforms from 
> <map:transform src="*2XHTML1.xsl"/>
>>and HTML will be supported). 
> <map:transform src="*2HTML.xsl"/>
>>Transformations from HTML and XHTML 
>>will be done in the core, while all others will be done by plugins 
>>(input plugins).
> Why?
> IMO only <map:transform src="*2XHTML2.xsl"/> belongs in the core. 
> We have to create just one contract about the internal format that
> forrest is based on.

That is right, and what Nicola was saying, you misread his comment, he 
said *from* XHTML1, not *to* XHTML1 - hence they are input plugins.


>>Metadata about a page can be added, like the date, page size, etc.
> That leads us to the question where to store metadata (example file
> my.xml). BTW this is taken from a mail I never send to answer the
> "Selective pdf" thread.
> 1) within each file as inline element.
> <page>
> <metadata type="pi" output-include="rtf,pod,pdf" output-exclude="html"/>
> </page>

No - it is clumsy to manage and clutters the content. It also increases 
processing time for each page since the file will be larger yet we often 
  only want the meta-data or the data.

> 2) outside of the file
>   a) in an extra file like my.metadata.xml. For each input file exist 1
> metadata file.
> <metadatas>
> <metadata type="pi" output-include="rtf,pod,pdf" output-exclude="html"/>
> </metadatas>

Good, clean, easily maintainable.

Linked to original file with:

<a href="URL" rel="meta" src="URI"/>

>   b) in an aggregated metadata file. Kind of like site.metadata.xml.
> <metadata-site>
> <metadata node="about/index" type="pi" output-include="rtf,pod,pdf"
> output-exclude="html"/>
> </metadata-site>

This can be generrated from 2)a) if it is needed.

Output-include and exclude stuff is not meta-data, it is configuration 
for a publishing format, it is not data about the data.

> 3) in the site.xml like Sean suggested + modification

No - mixes concerns and clutters the sites structural definition.

> 4) in RELAXNG?
> ...

Could you expand?

>>Nuggets of information can be added based on the URL and on the contents 
>>of the main source. For example, newsfeeds about the page being processed.
> Should go to the metadata like
>  <metadata type="nuggets" name="contractName1, contractName2"/>
> This way the skin can pull the actual needed content later on (faster).
> The information about which nuggets are needed could be stored in ft.

These are not meta-data, they are content and therefore should be 
referenced from the main content document.

We need a clear definition of meta-data. I believe it describes the data 
in a concise manner - keywords, location, license, description, 
classifications, cross referencing, that sort of thing.

I believe the description of what content should be included belongs 
with the rest of the content, i.e. in the document itself (optionally 
configured by the request URI). Therefore, our content documents will 
reference our nuggest:

<a rel="subsection" src="feeder?URL=" 

(NOTE: I have no idea if we can just invent a mime-type like this, I 
know there is a procedure to follow for registering them but is it 
appropriate here, is there a more appropriate solution?)

for definitions of the attributes src and type.

 > What I missing is:
 > fbits can be added based on the URL and on the contents of the main
 > source. For example, specific searchbox for the page being processed.
 > Should go to the metadata like
 >  <metadata type="fbit" name="contractName1, contractName2"/>

See below for comments about fbits.

>>Step 4: Skinning (presentation)
>>Based on the skin specified, the content is transformed in a format that 
>>contains presentation information. Example formats are html, fo 
>>(formatting objects) and svg.
>>Note that this part adds functionality to the content.
> better "adds functionality implementations to the content", because IMO
> we should store just metadata in our XHTML2 output and let the skin
> decide how to actually implement it.

Reading the above paragraph with your definition of meta-data (what I 
claim is actually content) then we agree. The skin reads the info about 
the embedded nugget (i.e. <a rel="subsection" 
src="feeder?URL="/>) and decides what to 
do with it, it may ignore it.

>> For example, a 
>>search item can be displayed, or widgets can be used. These are fbits, 
>>or functionality bits, and are different from nuggets, which are extra 
> They are different, indeed, but still they have a lot in common. Some
> nuggets will request a special functionality and vice versa. This will
> depend on the skin. That is why I think we should store such information
> (nuggets & fbits) as metadata first and implemend them now in this
> stage.

My comments above relate to nuggets. An fbit is not part of the content 
and therefore is not defined as content (as described by Nicola). fbits 
are described in the skin and configured for a project in skinconf.xml 
as they are now.

Hmmm... maybe the solution Sean and I are working on for selective PDF 
is putting the configuration in the wrong place, we are working towards 
putting that config in, but my comment above says it 
should go in skinconf.xml. Does this mean we configure fbits in skinconf 
and nuggets in

>>Note that fbits are skin dependant, so that a skin can decide to 
>>implement them or not. 
> So are nuggets. 


> That is why we need to insert this decision earlier in
> our pipeline. That needs to go into the filtering state.
> Trying to say that skins as well filter the content. That are views on a
> certain set of data. Remember that I earlier ask about views? ;-)

You did, but in a different context, it said:

 >>Multiple formats can be asked for the same source: the filename asked
 >> will be in the following manner.
 >>    name.type.format
 >> IOW:
 >>    myfile.content.html
 >>    myfile.javadocs.html
 >>    myfile.html
 > Is this like views?

I'm not making the connection, can you expand?

>>The configuration of these bits are to be done 
>>with the new generic skinconf format.

Hehe, I'm replying as I read, seems Nicola had already planted the fbit 
configuration idea with his previous post!

> That is as well filtering. The ft-approch filters fbits and can filter
> nuggets.
> <forrest-template>
>     <fbit name="branding-trail-path"/>
>     <hook name="intro">
>       <fbit name="grouplogo"/>
>       <fbit name="projectlogo"/>
>       <fbit name="search-input" type="sport"/>
>       <nugget name="sportNews"/>
>     </hook>
> </forrest-template>
> That is why I am thinking ft and skinconf.xml has to be proceded in
> filtering stage. -> copyless ;-)
> The skining stage has to implemend the actual data, fct, ... by pulling
> it in.

The above forrest-template mixes content (the nuggest) with 
functionality (the fbit). Content should be dealt with prior to this 
stage, in the filtering stage as you suggest. However, the fbits are 
part of the skinning process since they do not generate content on some 
form of interface (skin) to functionality.

Please remind me, exactly what is the forrest-template used for?

(although I have never been comfortable with saying the logos are fbits, 
they have content, I believe they are therefore nuggets.)

>>Step 5: Theming (presentation)
>>Here the result of the skinning is given to theming, that adds colors 
>>and general appearance info. In html it's css files for example, or the 
>>skinconf color information.
> Please extend.
> Why is this another stage? What is the big differents to skinning? 
> We are processing the needed information earlier in our pipeline why
> here again?

I think Nicola is making the distinction between skinning (what goes in 
the final page, i.e. search box, font size buttons etc.) and theming 
(how it the page looks in terms of positioning and colours).

> BTW did you notice that Nicolas [RT] is a pipeline that could be within
> a plugin itself (forrest as meta-plugin)? ;-) 
> We should focus on the forrest core (controller) as meta-plugin
> contoller. This plugin controlls all other forrest plugins.


This is essentially what Eclipse is, a simple framework for plugins. It 
is amazing how configurable that is, both internally and externally 
(many plugins are of use outside of eclipse, for example the SWT 
graphics and JFace widgets).

The same could be true for Forrest Plugins, for example, Lenya utilising 
the input and output plugins.


View raw message