cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Hartle <>
Subject Re: [BUG] DTD validation shows bugs
Date Fri, 14 Dec 2001 09:16:09 GMT
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 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 

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

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:
For additional commands, email:

View raw message