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:
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. 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. 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]
