Joerg Heinicke wrote:
<snip/>
> I validated the file using jEdit - I hope it did it correctly.
> 'validate-xdocs' does not work at the moment. From the messages
> yesterday I guess you know this, but here is the message:
<snip/>
Oh damn. I was sure that worked for me yesterday. I was obviously
mistaken because it fails now.
Do not worry about the System Identifiers for the DTDs. They are not
used at all (however see below). The catalog entity resolver does work.
It finds the DTDs from WEB-INF/entities based on the Public Identifiers
and ignores the hard-coded System Identifers. If ever we see different
behaviour (such as now) then we know that something is wrong.
I will try to explain the various issues that we are faced with today.
The Cocoon webapp is producing the documentation okay. The parser
there uses the catalog entity resolver with great success. ... okay.
The 'build docs' target, which now uses "forrest" directly, also uses
a catalog entity resolver. ... okay.
Forrest has a 'validate-xdocs' target which uses Forrest's Ant (v1.6)
and its xmlvalidate task. That uses the xmlcatalog/catalogpath and
refers to Forrest's OASIS catalog and the DTDs in Forrest. ... okay.
Cocoon has a 'validate-xdocs' target which uses Cocoon's Ant (v1.5.3)
and its xmlvalidate task. The xmlcatalog/catalogpath is not in this
version of Ant, so we cannot utilise Cocoon's OASIS catalog and DTDs.
We need to rely on the hard-coded System Identifiers. ... bad.
Anyway we recently removed the copies of the DTDs, so now it is
really broken.
We also do some specific validation of certain core configuration
using RELAX NG and the Jing task. This works fine for validating
the cocoon.roles file (note it has an internal DTD subset). We were
also doing some experimental validation of other files, such as
**/book.xml files. However, there are problems now, because the parser
that is used still needs to resolve the DTD. I presume that it does not
use an entity resolver, so it has to rely on the System Identifier,
which is now broken. ... bad. So i just removed that experiment from
the build.
--0--
The solution is to just remove the validate-xdocs target from Cocoon.
This then leaves it to Forrest to do the validation while it is
building the docs.
For those that don't have Forrest and still want to do xdocs editing,
they can do validation with their own xml editing tools or use a
special-purpose validator such as "xmllint", or "onsgmls" from OpenSP.
Just point the tool to Cocoon's catalog files at
WEB-INF/entities/catalog
The Cocoon validate-xdocs target has passed its use-by date. It was
good for the time because it helped us to maintain our xdocs. We can
now pass that concern on to other processes.
--David
