David Crossley wrote: >You seem to have terminology mixed up a bit. > Okay, I agree - it was late when I composed the email, but I will try to correct the message.
>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. > When using OpenOffice-produced content, I first stumbled on the <!DOCTYPE PUBLIC "-//somthingIcannotremember//-" "office.dtd"> declaration in the content.xml file; when the parser came across the file, it tried to look up the DTD, which was not there, resulting in an error whenever I tried to process the content. After looking around, I found the office.dtd plus several files that are included in there in a subdirectory of an OO installation. I then added a new subdirectory called "openoffice" to "resources/entities" and added the proper declaration to the catalog configuration file as well. The error about the lacking DTD then vanished, but my sample still did not work as expected, producing exceptions. To make a long debugging and tracing-through-classes story short, I finally traced the reason for the problem back to the ResolverImpl and somehow remembered this particular commit message which I then found at marc.theaimsgroup.com. After reverting this patch, both the entity resolution catalog and my sample worked perfectly. I might be wrong and currently I cannot remember it exactly, but I believe that before I reverted the patch, I turned up verbosity and tried the entity resolution catalog sample on the welcome page - I think it then failed, too. >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) > Searching for "validation", I could not find anything that relates to a parser validation switch in documentation/cocoon.xconf in the Cocoon 2.0 release. >Also, entity resolution will need to happen in any case (i.e. even >if parser validation="false"). > I did not touch a switch like that, so I guess the default setting would apply here. >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. > Anything that travels inside the pipeline is XML, so when the generated XML is e.g. an XHTML conforming file, it must be possible to directly serialize this; this has been working perfectly so far when the XML contained no DOCTYPE declaration at all. When developing, I start with the basic combination of generator and serializer, then slowly adding transformers and visually controlling the serialized XML step by step until all transformations are being done correctly and the resulting markup is the way I want; finally I switch the serializer type to what I need, obtaining the final output. It is not something I tried to achieve first hand, rather a behaviour I stumbled across when starting my work without a transformer in a pipeline. >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. > Sorry to spoil the party, but this particular system of mine is a Windows NT 4.0 server, running on JDK 1.3.1. >--David > BTW, should you come to Frankfurt/Main, Germany one day, mention it and feel yourself invited to a beer or two. By adding the OASIS catalog capability to Cocoon, you pretty much saved me a lot of work in my current project ;) Best regards, Michael Hartle, Hartle & Klug GbR --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
