forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: Docbook as forrest-plugin
Date Tue, 26 Oct 2004 21:08:41 GMT
Sean Wheller wrote:
> Well. Speaking personally, I am more in favor of having a system that works 
> 100% than having to suffice with a system that works 20% - 70%, depending on 
> the source formats.
> I understand why people want "intermediate format," but this is not a true 
> solution. It's a work around to get something working. Forrest is now past 
> 0.6 and needs to "grow-up." Sorry if that sounds bad, but I mean it with good 
> intentions. The best route is XHTML. That mean XHTML1 for now.

I don't understand what you are saying. XHTML2 *will* be our 
intermediate format.

> Forrest tries to take lots of responsability upon itself. While this is 
> admirable, it does not always result in the best and most flexible solution. 
> I think that the future for Forrest is good if the project can read in 
> standard formats.

We agree, where do we say or intend that Forrest should not do this?

> The number of formats is endless.  Already, the number of stylesheets 
> supporting conversion to another format are growing in number. They don't all 
> implement a full support for the target format. In addition, Forrest must 
> develop them while the sources of these formats are always changing. That's 
> an impossible task.
> IMHO it is better to harness the power the community (I mean other projects) 
> than to do it ourselves. We just need to define the format we accept, as 
> yourself and others have said, this means HTML or XHTML (1,2). I am in favor 
> of the later and I have no doubt that the Docbook community will develop 
> stylesheets for XHTML2.0 and the will when the "Longhorn Help System" is 
> released.

We agree. A lot of words to agree violently :-)

> I don't believe the power of forrest is in transformation to all formats. I 
> think it is in providing a publishing system that can accept input from the 
> numerous source formats out their and make it accessible. 

It's both ways.

Look, what Ross is trying to tell you is that we want Forrest to have a 
*single* intermediate format to which all source formats - directly *or* 
indirectly - are to be transformed, and from which all output formats 
are generated.



   myFormat -->  XHTML ------------>  - XHTML2 ---> HTML
   myformat2 -> DocBook -> XHTML --> /          \---> PDF
   POD -------> DocBook ----------->/            \--> POD
   HTML ------> XHTML ------------->


   myFormat -->  XHTML ------------>  - XHTML2 ----> HTML
   myformat2 -> DocBook -> XHTML --> /          \---> PDF
   POD -------> DocBook ----------------------------> HTML
   HTML ------> XHTML ------------->

We know that we *may* loose some information in the conversion, but ATM 
the benefits outweigh in our opinion the drawbacks. To change this, I'd 
like to see concrete examples that show the problems.

> The power of transformation and level of presentation/complexity in projects 
> such as DITA, TEI and Docbook is stronger than anything we could do by 
> ourselves. Why not harness that power?

If you say that Forrest must be able to do multiple transforms in order 
to harness the benefit of other projects, I totally agree. It's a good 
suggestion. Given the above assumption of an intermediate format, that is.

>>This coupled with the problem above (you cannot output consistent PDF
>>documents with the skin I choose to use) means that, as I have always
>>maintained, bypassing the intermediate format will be a mistake.
> Perhaps. But customization of the look and feel is not a problem. We just need 
> to decide on a standard look. In XHTML it's CSS that does the work. In PDF 
> etc. its the xsl:fo. Once we have custom layers we can enjoy the power of 
> packaged transformations and focus on making them look the same.

Please expand, it does not seem clear to me.

>>Hmmm... if there is a real problem with XIncludes it should be fixed in
>>the core of Forrest not in a plugin.
> The problem is bigger than you may think. Fixing the current system while 
> their is the intention to move to XHTML is just useless as we will build it 
> and then throw it out in a short time. I would prefer to develop something 
> that has a longer shelf life.

I don't get this.

>>I think you are missing the point of Forrest. You are supposed to be
>>able to put any input in and get out any *skinned* output. The idea of
>>the skin is you change a single property and that is it. Skins can be
>>maintained by Forrest or by individual projects.
> Ahhh.... but what level of support. The level of execution currently available 
> is 2/5 that of what it should be to be considered professional enough for 
> commercial consumption.

Level of execution? I don't understand.

>>What you are proposing is that all skin developers create a special
>>transformation for Docbook sources for *all* output formats forrest
>>provides. The current system does not require, it requires one
>>stylesheet for each output format.
> Not quite. Am am proposing that forrest expect to receive input in a standard 
> format that can be consistently skinned as per the project wishes. This 
> extends to include all presentation type formats that forrest may provide 
> access to.

Ok, we propose XHTML2. Is this sufficient?

> The difference between our thinking is that I don't believe the current 
> transformation system is:
> a) strong enough to support complex requirements.
> b) easy to manage as requirements and standards change (thinking XSLT 2.0)
> c) an efficient use of development time.

Too generic, throwing cheap shots will not help :-)

Please be more specific, what do you intend by *transformation system*?

>>By using the intermediate format of Forrest we don't need the Docbook
>>community to provide that support, they stay focused on their XHTML
>>stylesheets, we stay focused on maintaining out XHTML->intermediate
>>Less work for the Docbook community, less work for Forrest community and
>>more supported formats (anything you can get in XHTML will be supported
>>by the XHTML->intermediate stylesheets).
> Yes, but you can't get POD, DVI, PS etc in XHTML.

in XTML? *From* HTML? I don't understand.

What you say is interesting, but it seems that there is a lot of noise 
in the communication. Mails are getting long and it's difficult to go 
forward. Could you please be more specific on what you would need 
Forrest to do and in which way this cannot be achieved today? It would 
help us getting focused.

Much appreciated, keep things coming :-)

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

View raw message