There was a lengthy discussion on [EMAIL PROTECTED] that I'll summarize succinctly as:
1) Somebody requested a centralized location for Apache DTDs. 2) The request was turned down because of the load that resolving DTDs puts on Apache resources; DTDs should be accessed locally. Andrew and I chatted about this on IRC today because I've been confused about what kinds of operations this applies to and how to best address them. I have actually been vaguely aware of the issue since ApacheCon Europe when David Crossley (Forrest) mentioned that people using tools to edit forrest XML files should not be connecting to forrest.apache.org to resolve the DTDs. Since my XML editor is vi (and does no XML validation, for good or ill), I let this issue move to the background; however, I have been vaguely aware that every time I build the Derby web site it does in fact get the DTDs from forrest.apache.org. And after the discussion on the infrastructure list I realize that I do need to change this. So, to cut to the chase ... The Derby DITA doc builds are set up so that when you run ant to build the docs ( see http://db.apache.org/derby/manuals/dita.html for details), ant copies the DTDs from the DITA Toolkit into src/dtd in the Derby doc repo. The DITA files then include the appropriate DTD with a local, relative reference ("../dtd/concept.dtd", "../dtd/reference.dtd", or "../dtd/task.dtd") I logged DERBY-1199 to fix the Derby web site source. Andrew and I discussed a strategy similar to the DITA one: simply commit the forrest DTDs to the Derby web site repo and put relative references in the XML files. I'm also looking into a link that Crossley posted to infra (http://forrest.apache.org/docs/catalog.html) to see if I can use an entity resolver for the build itself (as opposed to for editing tools), and if this can be done in a way that is super easy for other Derby web site builders. I'm still spinning up on the technical considerations and solutions. -jean
