Victor Mote wrote:
Peter B. West wrote:
...
It seems to me, on reflection, that I had this completely wrong. They can't get out of sync *while they have a PUBLIC identifier.* I am still naive about such things, but doesn't the assignment of a PUBLIC ID ammount to a contract that the document so named will never change? If you want to change it, you must assign another PUBLIC id, because people all over the net are relying on the constancy of the association between the original PUBLIC id and the actual document.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.
That means that it is perfectly safe to keep local copies of the documents, as long as you get the association right.
I reviewed this exchange, and found that we had the same concern; a desire to be able to make changes to the documentation without having to have a local forrest installation for validation and rendering. Your (and Keiron's) initial suppositions about this were the same as mine.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.
I don't understand what went wrong when Keiron tried this,
> http://marc.theaimsgroup.com/?l=fop-dev&m=103726721907599&w=2
but I wonder if cocoon is misbehaving by using the SYSTEM id instead of the PUBLIC id.
<quote>
Unfortunately it does work like that.
To get the verification to work I need to add just the local public ID,
so it uses the forrest one to verify forrest ID's and the local one for
the local ID.
Then when it is copied across cocoon can only find the ID for the fop
dtd and the others are missing.
If I put all the forrest+fop ID's in the catalog then it cannot verify
as it cannot find the forrest dtd's relative to the catalog.
</quote>
Keiron, when you say "local PUBLIC id", are you referring to last component of the PUBLID id, containing the SYSTEM url? If a local copy of all of the forrest DTDs were maintained, and the FOP catalog pointed to that, then the problem of rendering locally or rendering remotely would come down to making the renderer (cocoon + forrest) use the correct (local or remote) catalog.
fop forrest(local) forrest(remote)
schema schema schema
| catalog | catalog | catalog
| | | | | |
dtd etc. | dtd | dtd |
*.dtd <-+ *.dtd <-+ *.dtd <-+
These DTDs are, I believe, set in concrete by virtue of their common PUBLID id (irrespective of the SYSTEM component of those ids, which can be completely ignored if a catalog is in place.)
At this stage we are not even talking about any local extensions, are we?
Peter
--
Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/
"Lord, to whom shall we go?"
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
