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" "http://cvs.apache.org/viewcvs.cgi/*checkout*/xml-forrest/src/resources/sche ma/dtd/document-v11.dtd"> 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: http://marc.theaimsgroup.com/?l=fop-dev&m=103726556406364&w=2 http://marc.theaimsgroup.com/?l=fop-dev&m=103726721907599&w=2 http://marc.theaimsgroup.com/?l=fop-dev&m=103730698919444&w=2 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]
