Victor Mote wrote:
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.

Norm Walsh has been campaigning for catalogs for a while now. E.g.

I don't have the luxury of permanent net access. Neither do you if is down or your access to the net is cut for any reason.

I think many apache developers would be in the situation that their work on open source must take place _away_ from their employment environment, and many of these would not have broadband or other permanent access. I think that factor is worth considering.

"Lord, to whom shall we go?"

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

Reply via email to