forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ivelin Ivanov" <ive...@apache.org>
Subject Re: draft howto dtd
Date Mon, 27 May 2002 17:24:00 GMT

Good points.

----- Original Message -----
From: "Robert Koberg" <rob@koberg.com>
To: <forrest-dev@xml.apache.org>
Sent: Sunday, May 26, 2002 12:10 AM
Subject: Re: draft howto dtd


> 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 :).

Can you suggest a concrete (preferably standard) technique for documents to
use links from within book.xml?
It has been proposed that W3C Topic Maps can be useful.
http://www.gca.org/papers/xmleurope2000/papers/s11-02.html

How about using the document link tag like this:

<link href="document({$bookDocument})/menu/menu-item[@id='howto-step1'">

Where the bookDocument variable is passed in from the sitemap.
This will require that the document files are not plain xml files, but xslt
files instead.
To keep things clean maybe the <link/> tag can be extended with syntax like:

<link href="book/howto-step1"/> or similar.


> 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 agree that the map:aggregate in the sitemap is somewhat redundand.
What are its advantages over passing the components as parameters to a
normal XSLT page
which includes them either through include/import or the document()
function.
The advantages that I see in the latter approach are that its utilizing XML
standards.
It also allows use of namespaces in the aggregating document, allows
references to validation documents,
and everything else you can use in an XSLT document.
Additionally the link referencing suggested above is natural.


Cheers,

Ivelin


>
> 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
> >>
> >>
> >>
> >>
> >
> >
>
>---------------------------------------------------------------------------
-
> >----
> >
> >
> >
> >
> >>
> >>
> >>
> >>
> >
> >
> >
>
>


Mime
View raw message