Re: forrest DTDs
copying this to forrest-dev for feeback. Thanks :-) Victor Mote wrote: 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 r additional commands, email: [EMAIL PROTECTED] -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: forrest DTDs
Victor Mote wrote: Keiron: It looks like most of the documents in src/documentation/contents/xdocs use Public IDs for their DTD declarations. The forrest web site indicates that it has a catalog that maps these Public IDs. However, it looks like one has to download forrest to get either the catalog or the DTDs. Do you think it worthwhile to include the catalog DTDs in the FOP cvs (perhaps in resources/schema/dtd/forrest ??) so that developers can get to them without needing to download forrest? Alternatively (or perhaps in addition), we Hmm .. if you are working on the documention you'll need forrest anyway to render the pages. could suggest to the forrest group that they make these items directly available on their web-site. http://cvs.apache.org/viewcvs/xml-forrest/src/resources/schema/ Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: forrest DTDs
Hi Victor, I wouldn't recommend putting the dtd's in our cvs, one version is better. 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. You still need forrest to do the verifying and generation. It seems I spoke too soon about verifying. 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. Keiron. On Thu, 2002-11-14 at 10:19, Victor Mote wrote: Keiron: It looks like most of the documents in src/documentation/contents/xdocs use Public IDs for their DTD declarations. The forrest web site indicates that it has a catalog that maps these Public IDs. However, it looks like one has to download forrest to get either the catalog or the DTDs. Do you think it worthwhile to include the catalog DTDs in the FOP cvs (perhaps in resources/schema/dtd/forrest ??) so that developers can get to them without needing to download forrest? Alternatively (or perhaps in addition), we could suggest to the forrest group that they make these items directly available on their web-site. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: forrest DTDs
Christian Geisert wrote: Hmm .. if you are working on the documention you'll need forrest anyway to render the pages. I don't really want to render the pages, just work on the content. could suggest to the forrest group that they make these items directly available on their web-site. http://cvs.apache.org/viewcvs/xml-forrest/src/resources/schema/ Thanks. That is it, sort of -- and now that I know about viewcvs, I'll probably use it other places. What I am trying to do is to make sure that it is as easy as possible for any developer to quickly make a change to the documentation. The link above is a step in that direction. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: forrest DTDs
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]
