forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Wheller <s...@inwords.co.za>
Subject Re: Docbook as forrest-plugin
Date Wed, 27 Oct 2004 06:32:11 GMT
On Wednesday 27 October 2004 01:24, Rick Tessner wrote:

Thanks for the input.

>
> Right now, we seem to be stuck on this idea of the intermediate format
> which I think we're all agreed we need in order to be able to present a
> consistent look and feel.  
> Currently, that format is document-v12 and in 
> the future will be a subset of XHTML 1.0 or 2.0.

Ouch there we go again, that word "subset." When will forrest do it properly? 
Can we really expect Forrest to be a robust product system if we put it in a 
box. I am happy with XHTMLX.X, but not a "subset." I won't ramble on as to 
why.

>
> What if the intermediate format was instead an intermediate pipeline of
> Docbook -> XHTML?  Anyone desiring to use a new input format within
> Forrest would produce XML which conforms to a format in the intermediate
> pipeline.

Hmmm, Interesting. Not quite what I was thinking but interesting thought.
What I thinking is that any source format that can transform to XHTML can be 
piped through forrest without information loss.

If a "subset" of XHTML is used, then there is bound to be information loss.

>
> We would be able to leverage all the work that has been done in the
> Docbook community in transforming to XHTML (and XSL:FO).

Yes, and other projects. Most of them provide an XML/XSL transformation 
system. Why develop this on our own, plug-in under forrest and you're away.

> With Docbook's modular style, we should still be able to layer whatever
> bits are necessary on top of the XHTML produced by Docbook to take care
> of the stylings.  Ditto with the XSL:FO.

Layering is good, this is why I have started with a custom layer. That portion 
of the plug-in and its sitemap.xmap are for forrest. The rest is docbook. BTW 
when I say docbook I mean both Full and Simplified.

Yep, that's it exactly. On top of the XHTML produced by Docbook and DITA, and 
TEI and ANYTHING ELSE.

I don't see the need for an "internal format" when you can read and support a 
full XHTML, NOT A SUBSET. Why stunt forrest. 

XHTML FULL IS NOT an INTERNAL FORMAT it is a TRANSITIONAL STANDARD FORMAT.
XHTML FORREST SUBSET IS an INTERNAL FORMAT it IS NOT a TRANSITIONAL STANDARD.
 
XHTML extends beyond forrest. When I think "internal format" I think 
"proprietary", like the document VX and "subset of XHTML."

>
> Any existing XSL that people have which transform into XHTML (or HTML 4)
> would still work within the pipeline.

Yes, and keep the overhead of its maintenance and development with people who 
better understand and are more focused on the subject.

>
> Thoughts?
>
> I do have a couple of concerns tho:
>
> 1.  I used Docbook a few years back and the performance was not a
>      wonderous thing due to all the imports / includes that were
>      necessary as part of its modular design.  Might not be the
>      best for a servlet based Forrest site.

Yes, it can be heavy. Performance will reduce on large documents, books, sets. 
For small documents like articles it is not a problem.

In fact for large documents I would almost always generate a static content 
and then feed that in. In our case it will be XHTML. For Docbook users this 
should not be a problem. Most of their content is in some type of Document 
Management System. The process is to edit, proof, release, publish. The 
publish goes to many formats, one may be XHTML/HTML that is piped into a 
Content Management System. Hence there is little need for servlet.


> 2.  What about the wholesite.pdf / wholesite.html / tabs-as-pdf bits?
>      I don't have a good enough feel for Forrest yet as to what would
>      happen here.

Good question? Won't it work the same as it does now?

-- 
Sean Wheller
Technical Author
sean@inwords.co.za
http://www.inwords.co.za

Mime
View raw message