forrest-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <>
Subject Re: Support for XInclude in tabs.xml and site.xml
Date Tue, 18 Jan 2005 16:14:22 GMT

Sjur Moshagen wrote:
> På 15. jan. 2005 kl. 18.05 skrev Ross Gardler:
>>> Do you see where we are heading? Does it make sense, or could there 
>>> be better ways of doing it?
>> There are two other ways that we are aware of, but neither is fully 
>> implemented as yet.
>> The most complete solution is implemented in the IMSManifest block. It 
>> has been agreed that it should be extracted to the core and made to 
>> work in site.xml. It is in that block simply because the project 
>> needing it was implemented using IMS Manifests.
>> Our solution is to import content from a repository.
> This is also what we do.

With one very important difference, for us, Forrest does it at runtime. 
There is no need for the content developers to import the docs, this is 
very important for us as most of our content developers are not 
technically aware, using a word processor is about their limit.

>> The big advantage of this is that Forrest automatically gets the 
>> freshest content from the repository each time the site is built. Of 
>> course, this is also a disadvantage as the site can't be built if we 
>> don't have access to the repository (i.e. you need to be online). 
>> Perhaps the answer is to have forrest checkout the remote content from 
>> CVS/SVN as you do, it can manage the updates etc. locally.
> We should probably deal with the two issues separately:
> 1) flexible inclusion of what is wanted
> 2) update/checkout of the local copy
> 1) is very easily handled with XInclude - all xpath handling is already 
> there.

With Forrest as it currently stands, XInclude is only sufficient if the 
source is available locally. For us the repository could be anywhere.

> 2) I have no concrete suggestion on this one.

At present we use the document() function of XSLT to bring in the remote 
  document. This means we can provide a pipeline that pulls the data 
from the relevant repository (here I am referring to CVS/SVN type 
repositories for you and Learning Object repositories for myself). This 
pipeline can be responsible for managing a local cache of the data.

>> I'd be happy to work with you on extracting this functionality to core 
>> and enhancing it accordingly. It seems you have a similar use case to 
>> mine.
> I'll have to look into IMSManifest. Presently we (or I, that is:-) would 
> like to go for the XInclude solution, to get our site up and running 
> AFAP. That does not preclude that we also look into other solutions that 
> would also take care of repository checkouts/updates.

Absolutely, you need to get things working for your project (and I will 
apply your patch since it does not affect other aspects of Forrest).

I just thought that we have an amount of overlap between our two use 
cases and wanted to explore that. I suppose the real question I should 
be asking you is "would automatic management of included documents be a 
benefit in your case?"

> One of our concerns would be i18n - we can only live with a solution 
> that integrates well with the i18n work done (and planned) in Forrest.

Well I have not done any work with i18n, but I see no reason why our own 
approach should br3eak this functionality since everything is converted 
to a site.xml and tabs.xml file and then handled internally by Forrest 
in exactly the same way.

This means that improvements to the core i18n funcitonlaity should be 
avilable to all solutions.


No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.7.0 - Release Date: 17/01/2005

View raw message