Peter B. West wrote:

> I'm still floundering around here, but when I found 'catalog' in
> .../documentation/resources/schema, and the dtd in .../schema/dtd, I
> began to see a ray of light.  It seems to me that such a setup should be
> used for all of the DOCTYPE delcarations in the documentation tree.  At
> the moment we are relying on the system identifier component of the
> DOCTYPE declaration, and that is indicating a CVS retrieval - some from
> the xml-forrest base, some from xml-cocoon2, last time I looked.

The way this works is that your validation software has to know how to find
the catalog. If it does, then the catalog can contain mappings from the
PUBLIC IDs in the DOCTYPE declaration to a local physical file. That setup
is already in all of our documents. For example, our resources.xml file
contains the following DOCTYPE:

<!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.1//EN"


Your catalog has to know how to map "-//APACHE//DTD Documentation V1.1//EN"
to "/u/xml-schema/document-v11.dtd" or whatever your local file is.

What I added several weeks ago was the URIs (yes, they are CVS-based until
we find some static URI to use instead) that allow the validation to be done
across the internet. This doesn't take away the ability to use a local
catalog, but rather makes it no longer a necessity. My understanding is that
using URIs is the preferable way to do the validation. O'Reilly's "XML in a
Nutshell", 2nd edition, page 32, says "In practice, however, PUBLIC IDs
aren't used very much. Almost all validators rely on the URI to actually
validate the document." The only reason to use the catalog and the PUBLIC ID
is if you are on a machine that doesn't have suitable net access.

> These can (probably will) get out of sync. The dtd should be the one
> used when the document was last modified, shouldn't it?  It seems to me
> there is a case for including the schema subtree, including catalog
> file(s) and the dtd subdirectory, in the src/build tree, and maintaining
> the synchronization locally.

Keiron & I discussed this at the time:
and decided against it. Since I did this work, I see that we could use
viewcvs to get a specific revision of the file, so we could control this
using that method. However, it seems to me that DTDs conventionally have a
version number built into their filenames, so I assume that any changes made
on those files are of a bug fix nature as opposed to radical changes that
would be likely to mess up users of the DTD.

It seems to me that we have this set up as well as it can be, but I sure
could be missing something.

Victor Mote

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to