On Thu, Dec 12, 2002 at 11:48:16PM +1000, Peter B. West wrote: > Victor Mote wrote: > >Peter B. West wrote: ... > >>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. > > > > 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?
Will never _break_. It may change in backwards-compatible ways. Just like Java APIs. > 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. Yes. There is nothing wrong with FOP grabbing the latest DTDs from Forrest and including them locally. That is effectively what users of Forrest binary distributions do; they're using an old snapshot of the DTDs. > That means that it is perfectly safe to keep local copies of the > documents, as long as you get the association right. > > >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 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. Including the DTDs would IMO be a good idea. They are only 57k. The question is, what catalog-aware validation tool would you use? I would suggest upgrading the version of Ant bundled with FOP to 1.6-dev from CVS. This includes <xmlcatalog> support for multiple external catalogs. So after editing xdocs, developers could type 'build validate', and if everything passes, they can safely commit the xdocs. Then check on http://forrestbot.cocoondev.org if the changes look okay.. and one day, trigger an xml-site commit from that site too. Tada.. Forrest is no longer required for daily edits :) If this sounds decent, I can create a patch to add Ant-based local validation to FOP, and then document the process, as I'm sure lots of projects' developers hate having to download 13mb of Forrest just to update some stupid docs :) > 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's expectations were correct. That was a bug in a pre-0.2 version of Forrest. A small sample Forrest site illustrating the fix is at http://cvs.apache.org/~jefft/forrest/samples/ --Jeff ... > 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]
