Michael Hartle wrote: > Hello all, > > after working and starting to slowly get pretty impressive, nearly > presentable results on coupling Documentum, Cocoon, Slide and > OpenOffice together, I found out that DTD validation is still a bit > buggy in the Cocoon 2.0 release:
You seem to have terminology mixed up a bit. Do you mean "XML validation" to ensure that the structure of the XML instance conforms to the rules of its DTD? Or do you mean "entity resolution" to allow the parser to find a local copy of your new DTD? Your discussion below indicates the latter. The "entity resolution" should happen by default (as long as you have your "catalog" configured). The "XML Validation" you need to switch on via xconf (see documentation/cocoon.xconf) Also, entity resolution will need to happen in any case (i.e. even if parser validation="false"). > 1.) Whenever I used a pipeline like (any generator parsing XML with DTD) > => (no transformer) => (HTML serializer), the first character returned > and visible astonishingly was always a ">". I assume this is Xerces > related, as changing the serializer type to "xml" produces an > ArrayOutOfBoundsException in the Xerces parser. To see this live, take > the entity catalog demo in the sitemap, remove the stylesheet > transformation to see the first bug and then change the serializer type > to "xml" to see the second. Adding an XSLT transformer to the pipeline, > even if it does not change anything, seems to be a workaround for now. I do not understand what you are trying to achieve here. Generate XML => Serialize HTML does not make sense to me. Perhaps you are trying to demonstrate some other error. > 2.) After adding the OpenOffice DTD to the catalog and trying to > validate a content.xml with corresponds to the office.dtd, I encountered > the bug that whenever entities are to be resolved, the ISO*.pen files > are being searched in the same directory where the XML file to be > validated is located. This indicates to me that the whole entity resolver is not working. Are you sure that you have the catalog correctly configured? Raise the resolver parameter verbosity=3 in cocoon.xconf to see. I am currently updating my 2.0 working copy and will check myself. I was sure that i tested stuff after committing Christian's patch. Let us pray that Bug 5060 (platform-specific problems with file:) has not crawled back to life. --David > After reverting a recent change to > org.apache.cocoon.components.resolver.ResolverImpl.java submitted by > Christian Schmitt (see > http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=100691270713121&w=2), > this issue was solved and any XML content produced by OpenOffice has > successfully been validated so far. > > Has anyone seen such behavior too, or is it just me ? I am using a clean > Cocoon 2.0 release build with extensions like new generators, source > factories and the like which are closely modelled after existing > components. BTW, the Docbase source factory for interfacing Documentum > docbases yet has to be made configurable, but then it is close to donation. > > Best regards, > > Michael Hartle, > Hartle & Klug GbR --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
