forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Diana Shannon <>
Subject Re: Cocoon docs transition report
Date Tue, 18 Jun 2002 12:52:05 GMT

On Tuesday, June 18, 2002, at 07:45  AM, David Crossley wrote:

> Diana Shannon wrote:
> <snip/>
> Excellent stuff Diana. I will answer some other bits later.
>> o----------o
>> 1. We need to add jar.xml generation to Forrest docs build. John?
>> 2. We're don't seem to be catching all @XXXX@ tokens (e.g.
>> released.version) in cocoon xdocs during build filtering
> They are probably not defined in src/targets/project.xtarget

No, which brings up an issue. Can projects have customized build 
targets? Seems to me they will be somewhat different across projects. In 
addition to schema management, will Forrest manage such build changes 
(as well as sitemap changes). It's hard to imagine all project working 
from the same sitemap design, especially in the case of Cocoon which 
will probably want to lead with new sitemap design approaches. It's also 
difficult imagining projects going through Forrest for sitemap and build 
change "approvals." Am I misunderstanding the mission of Forrest?
>> 3. No time to look at example files.
> Not sure what you mean here ... the final HTML that is produced?

Yes. How we want to implement validation, if necessary. Remember, we 
need to pull example content out, somewhat, into the main docs to 
increase their visibility. There's also problems with dirctories like 
ctwig who include sample files with no dtds at all. It would be nice to 
perform wholesale doc validation, but define ways to skip files (without 
manually editing excludes/includes) etc. within a centipede target.

> If so yes, we need to spend time to be sure that most stuff is
> properly handled. We can cope with minor glitches later.

<snip />

>> 6. Most relative doctype paths to dtd were stripped during
>> transformation because of v10-v11 changes. I assume we don't need
>> relative local paths anymore, given the new path capabilities of
>> validation with xmlcatalog.
> We never did need relative paths for systemIdentifiers. The
> equally excellent catalog entity resolver in Cocoon and Forrest
> took care of it. However some people liked the belt-and-braces
> for impoverished xml tools. I prefer to rely on an entity resolver.
> These are XML Framework projects after all. Great to hear that
> Ant is starting to use one too.

Well, at least it will help contributors and committers who don't 
validate single or multiple page contributions with their standard 
tools. Up to now, I wasn't performing wholesale xdocd validation either, 
just the individual pages with which I was dealing.


View raw message