forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Crossley <>
Subject Re: [Proposal] add DTDs to Apache website
Date Fri, 13 Feb 2004 07:38:25 GMT
Thanks to everyone who responded. The discussion seems
to have gone quiet, so it is time to summarise.

I am not going to call a Vote on this, rather just do it.
If anyone thinks otherwise then say so.

These are the original set of issues. I have added comments
based on the discussion, and added the new issues that arose.
Issues 6, 7, 13, 14 are where the action is.

> 1) The DTDs will still be managed in the Forrest CVS.


> 2) The Forrest build system is complex. It would be good to automate
> the publishing of DTD versions, but that may not be possible.
> 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).

Issues 2, 3, and 4 are solved in one fell swoop by the use
of .htaccess and mod_rewrite magic. See Issue 13 below.

> 5) Extra impact on the Apache webserver. Is this a big bandwidth
> consumer? See some estimates in [4].

No comments, so don't worry about it.

> 6) What will be the URLs for the DTDs?
> We presume that Forrest will not be a top-level project soon.

This is the big problem. The XML Project is talking about
moving Forrest under the wings of Cocoon.

So we should anticipate that and use cocoon URLs:
or even

See also new issues 12 and 13.

> 7) Does the Apache webserver deliver the supporting files using
> the appropriate Content-Type? Is that "text/plain"? Does it matter?
> We have *.dtd and *.mod and *.pen and *.ent extensions.

Tests proved that there is a problem with some of these
with the default webserver config. Never mind, .htaccess
to the rescue. See Issue 13 below.

Steven posted an RFC which might help us to decide.
See the discussion, there are some outstanding questions:

> 8) We have two separate directories in CVS. The /dtd/ and the
> /entity/ directories are parallel. We can probably merge
> everything into /dtd/ and change the Catalogs.

No comments. Merge them, because the entity sets are only
used by DTDs anyway.

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

Do not use the "seed site" as a test mechanism. Add some
proper tests. Not sure yet whether JUnit or Anteater.

> 10) Cocoon has a copy of the DTDs and stuff in its own CVS
> so that it can build its own documentation via its webapp
> and command-line builds. This can still continue, but needs
> a better solution. Perhaps Forrest can provide later.


> 11) Do we need to ask infrastructure@ about this proposal
> or just do it?

No comments, so just do it.

The new issues ...

12) With the last Forrest release, the System Identifiers were
changed to be URIs instead of local paths, e.g.

This was unfortunate because now we need to handle the fact
that people will expect a DTD resource to be there. In the
upcoming Forrest and Cocoon release we will change all
default System Identifiers to be that adopted at Issue 6.

13) We are working on a .htaccess to rewrite the URLs to
deliver the resources via ViewCVS. This still needs some work.
See the previous message in this thread.

14) Test that it works. Yes, it does with XXE. Disable the
Forrest catalog.xcat then change the System Identifier in
one of your xdocs to point to
Does it work with other tools?

15) It was suggested to do the same for XSD and RNG for
the Sitemap. None published yet, so address this later.

16) It was suggested that we need a document to assist
with configuration of local XML Tools. Here is a start:

17) Need to make extra effort to ensure that we adhere
to the proper naming convention for our DTDs and increment
the version numbers for every change.


View raw message