Mailing-List: contact forrest-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: forrest-dev@xml.apache.org
Subject: Re: [Proposal] add DTDs to Apache website
From: David Crossley <crossley@indexgeo.com.au>
To: dev@cocoon.apache.org, forrest-dev@xml.apache.org
In-Reply-To: <40058CD0.2000704@gmx.de>
References: <1074056016.5794.13010.camel@ighp>  <40058CD0.2000704@gmx.de>
Content-Type: text/plain
Organization: 
Message-Id: <1074139557.5793.17651.camel@ighp>
Mime-Version: 1.0
Date: 15 Jan 2004 15:05:58 +1100
Content-Transfer-Encoding: 7bit

Joerg Heinicke wrote:
> David Crossley wrote:
> 
> > 3) The Forrest website is built using the "stable" version of
> > Forrest (currently v0.5.1). So how will DTDs from the current
> > CVS (v0.6-dev) get into the website CVS [3]? Manual copy? See 4).
> > 
> > 4) If some committer changes the DTDs in CVS then they will be
> > out-of-sync. Will committers remember to do the manual copy? See 3).
> 
> I don't see this problem. On the one hand there are the older files like 
> document 0.10 or 0.11 that won't be touched, on the other hand 0.12 (or 
> is it already old too?) which is developed at the moment. You can't make 
> incompatible changes for one version, otherwise you will break possibly 
> thousands of documents out there. So only extensions are possible.

Absolutely. I think that i got a bit mixed up with whatever i was
trying to say in item 4. We need proper version control and we
have a naming convention for that.

Forrest has been careful not to introduce any incompatible changes.
However, i think that we need to be more careful about adding even
new optional stuff. Every change should be a totally new DTD version.

> In 
> conclusion: the update cycle must not be once per minute, but maybe once 
> per day or only week. Now what about having a cron job running on the 
> website server that checks out recent DTD versions? Forcing manual work 
> that's critical and without much effort automatically doable sounds not 
> that good.

Good idea. Nicola Ken suggested something similar. I think that
we need to be careful how far the automation goes. I mean that
there are DTD versions in the HEAD CVS that are perhaps not yet
ready to go public. Perhaps a deliberate manual process is better,
but have a cronjob that reminds us if there are missing files
on the website.

> > 9) We will never know if the Catalog Entity Resolver gets
> > broken after an upgrade. Forrest will still work but will
> > be slower, doing downloads of the DTD and supporting files
> > on each document parse. We can probably add a test document
> > in the "forrest seed site" to detect failure.
> 
> A really bad argument against the proposal :) Of course a real test is 
> the way to go here.

I gather that you mean a "good argument". That is why i listed that
issue. It would be a bad thing if Forrest/Cocoon silently started
doing network retrievals like the current Xerces-2.6 web.xml issue.

Forrest does now have a "build test" target which tries to build the
"forrest seed site". Are you suggesting that we would be better to
re-instate the JUnit tests that Cocoon used to have? I am no expert,
but i think that we need the test to actually be a part of the
Forrest machinery so that when users create a new "project" then
they get the test happening too.

--David