Mailing-List: contact forrest-dev-help@xml.apache.org; run by ezmlm
Message-ID: <3CF06E29.7060103@koberg.com>
Date: Sat, 25 May 2002 22:10:01 -0700
From: Robert Koberg <rob@koberg.com>
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US;
 rv:1.0rc1) Gecko/20020417
MIME-Version: 1.0
To: forrest-dev@xml.apache.org
Subject: Re: draft howto dtd
References: <14C4A8F0-6831-11D6-A1FC-0030653FE818@mac.com>
 <00e801c2046a$5b2cc3a0$0c91fea9@galina>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

On the book.xml (menu/site-structure) and index.xml (content piece), for 
example: why duplicate link's href values - if you had access to 
book.xml (the menu or site structure) you could reference links by ID 
instead of a hard coded link. For example the content hard codes links 
to faq.html or http://xml.apache.org/cocoon. Why not have these in one 
location (book.xml) and refer to them? It would be nice to reuse the 
data provided by book.xml (perhaps even store more page level meta info 
there?? show-toc, show-meta-data, show-on-nav - or at the folder level: 
number-pages, show-on-nav - etc). Even better have book.xml be a 
representation of the entire site hierarchy. Then you can recursviely 
build paths to documents. For all the good book.xml does it could be 
written straight into the XSLT (and included :).

I still don't see what is wrong with using import or include to bring 
together many XSLTs into one. The cocoon way of performing multiple 
transformations seems like way too much work when you want to break your 
XSLT into component pieces for easy reusability.

I think you miss a *great deal* of the benefit of XSLT by not using the 
document function and import/include. I can't seem to come up with a 
good way to do the things I want to do without them.

I would love clear, explicit documentation on how to do things that are 
commonplace in regular XSLT but are to be avoided when using cocoon.

best,
-Rob


Ivelin Ivanov wrote:

>I just finished reviewing all pages on xml.apache.org/forrest
>
>Encouraging first steps !
>
>
>A few more almost-negligible notes:
>
>Typos:
>
>http://xml.apache.org/forrest/primer.html
>Forrest site generation using Cocoon
>
>The docs target of the Forrest build environment invokes Cocoon as a
>command-line application to generate an HTML rendition of the project's
>documentation. It is not within the scope of this document to explain the
>Cocoon internals, please read ***the its*** own documentation to fully
>understand the power of Cocoon.
>
>
>Cocoon responds by aggregating two 'sub-requests'. The first is for the
>resource book-{1}.xml, the second is for the resource body-{1}.xml. The {1}
>parameter is replaced by the ***valuse*** of the first wildcard in the
>matching pattern above. These 'sub-requests' are passed through the cocoon
>pipeline just like any other request. This results in the following flow:
>
>
>
>
>----- Original Message -----
>From: "Diana Shannon" <terracare@mac.com>
>To: <forrest-dev@xml.apache.org>
>Sent: Wednesday, May 15, 2002 1:25 PM
>Subject: draft howto dtd
>
>
>  
>
>>Attached is a howto dtd draft, along with a sample doc to validate. A
>>few notes.
>>
>>1. I think the header element contains a lot of useful cms-related info.
>>Perhaps version can be used to imply status: draft/release/revision. I'm
>>not sure of its precise meaning with code, but perhaps "draft" document
>>versions could have a value less than 1, etc.
>>
>>2. id attribute (via %common.att;) is defined for howto, so if CMS needs
>>to manage docs via that attribute, we're still ok.
>>
>>3. I declared one additional child element of header:
>>last-modified-content-date. Its purpose is to provide meaning to the
>>reader based on content changes, not mere structural changes, etc. I'm
>>not sure if it duplicates revision history structure at the bottom.
>>
>>4. I'm trying to take what is a liberal approach to what is allowed by
>>the dtd. For example, I didn't use %content.mix; anywhere. I wanted to
>>allow authors the chance to use lists for prerequesites, intended
>>audience, etc. Perhaps some of you will consider this too loose.
>>
>>5. Steve, I wonder if you're going to dislike the way I'm treating
>>titles (as attributes) in each howto part. I just found it a little
>>simpler to implement this way. Feel free to revise, in anticipation of
>>your v11 work.
>>
>>Anyway, please improve it. I'm certainly no expert. Snippets/tutorials
>>dtds will be similarly structured, so I'll wait for comments before
>>submitting those.
>>
>>Many thanks.
>>
>>Diana
>>
>>
>>    
>>
>
>
>----------------------------------------------------------------------------
>----
>
>
>  
>
>>
>>
>>    
>>
>
>  
>