Mailing-List: contact dev-help@forrest.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@forrest.apache.org
Received-SPF: neutral (hermes.apache.org: local policy)
From: Sean Wheller <sean@inwords.co.za>
Reply-To: sean@inwords.co.za
Organization: In Words
To: dev@forrest.apache.org
Subject: Re: Test Zone for new Forrest Sample Site
Date: Thu, 21 Oct 2004 08:28:40 +0200
User-Agent: KMail/1.6.2
References: <200410202107.48420.sean@inwords.co.za>
 <4176CA69.5000506@apache.org>
In-Reply-To: <4176CA69.5000506@apache.org>
MIME-Version: 1.0
Content-Disposition: inline
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <200410210828.40571.sean@inwords.co.za>

On Wednesday 20 October 2004 22:28, Ross Gardler wrote:
> Sean Wheller wrote:
> >
> > Here is a test site that will eventually be hosted at
> > http://learnlinux.tsf.org.za. All content except the FAQ's are Docbook
> > 4.3.
> >
> > The test zone URL is http://www.inwords.co.za/site/index.html
> >
> > Please check the courses section to see an example of the problem with
> > XInclude.
>
> I'm afraid I cannot address the problem you are having with XIncludes,
> but I do have a useful suggestion. First a little background:
>
> Some time ago I tried to do exactly what you were doing, that is
> XInclude content in course materials. I wanted to reuse content from one
> course in another (I guess this is what you are doing). I ran into many
> limitiations of the XInclude handling in Cocoon itself and eventually
> dropped the whole thing for cut and paste and careful management
> (deadlines and all that).

Yes, this is exactly what we're doing. It's called modular Docbook. We can 
implement it using two methods: entities or xincude. The problem with the 
entities is that you cannot have a DocTypeDecl in the referenced documents. 
This mean to have to transform from the driver (master document), in order to 
get output. This is not good since people sometimes what to take it one piece 
at a time. In addition there is the overhead of turning Forrest validation 
off for these documents.

XInclude is the way forward. Since it solves these problems. Seems that this 
should be listed as a major bug in Forrest. What do you think?

The problem here is that the sources must be transformable under forrest and 
under any other publishing tool chain. IMHO, this is the way it should be.

<comment>Forrest is a good idea, unfortunately it seems to have deviated from 
the standards in places and only partially implements them.</comment>

>
> Some time later I recieved a grant from IBM to build a system for
> building learning objects. This project (http://www.burrokeet.org) is
> now around half way through and is starting to produce real results. One
> of which will be of grat help to you.

Wow, what a find! Thanks.
>
> As you know I have been working on a plugin system for Forrest. The
> first plugin I have built for this replaces site.xml and tabs.xml with
> an IMSManifest file (this is the equivalent of site.xml for a SCORM1.2
> learning object). One of the functions of this plugin is that you can
> include content from one content object in another.
>
> Now, this is alpha code and has some problems (i.e. there is some
> hardcoded path information in the XMaps and xsl), however, it does work.
> I have used it for all the courses I have developed and we use it within
> Burrokeet itself.
>
> So, my advice to you would be forget XInclude and use this new plugin (
> I am hoping to merge the branch with trunk tomorrow). There is even a
> graphical editor you can use to create your IMSManifest :-).

Yes. I have been watching the sitemap-plugins branch. I have not tried it, 
time is the problem. Perhaps I should have, but I expected xi:include to work 
in forrest. I will take another look at it and try to implement it. Tough I 
am not sure about the "hardcoding". I understand why you have done it 
though :-)

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