Keiron Liddle wrote: > I wouldn't recommend putting the dtd's in our cvs, one version is > better.
In principle I agree. I think the best solution is for Forrest to make them available in a small download. > The are some pages describing the dtd but I presume you mean for > editing. I think it would be useful to make them downloadable separately > just for editing. Yes, I was referring to editing. > I think the process is something like: > - put your own catalog in resources/schema/catalog > - it will then verify with that catalog > - cocoon will use that catalog when copied across to webapps > > 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. > > So something is a bit broken. I am not familiar with cocoon, so I am a bit lost. However, the catalog concept is just for local use -- in other words for a specific editor/parser. Since Christian has shown us how to find the DTDs on the Web, we should probably add the URL in the declaration -- then people with always-on web access can see that one. The catalog is really just for standalone boxes without access to the URL version, to map the public ID to a local file. After I downloaded Forrest last night, I was able to add an entry in XML-Spy to see my local copy of the DTD. Without that mapping, and since the files don't have the URL, right now an editor will complain that it can't find the DTD in the current directory. Victor Mote --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
