cocoon-dev mailing list archives

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

That sound like the entity resolver activated then - good.

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

Well done. (See discussion of consequences below.)

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

Sorry, i meant 2.1 HEAD. That parameter is only documented there.
It is in the <parser> entry ... parameter name="validate"
(Careful, you will get troubles at this stage - hence 2.1
I tried some discussion threads last month about validation
but there was no response.)

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

Yes, default is no validation ... validate="false"

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

That sounds like an excellent approach - thanks for taking
the time to explain. I will adopt it.

So where does the spurious ">" come from? This was your
issue #1 in your original posting. I think that this is a separate
issue which would better be discussed in a new thread. What
do you think?

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

So it sounds like we do not need the patch at all - or is it
there for other reasons. 

What does this mean for the recent 2.0 release? ... i will look
tomorrow. It seems that, with the flurry of release and two
last-day showstoppers, platform testing was missed.

> >--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 ;)

OK, alternatively, or as well as, you could pop downunder :-)
We are coming up to a hot Aussie summer.

I knew that we would ALL need OASIS catalog capability.
My projects could not be done without it. Many thanks to
all for its beaut cocoon.
--David Crossley

> Best regards,
> Michael Hartle,
> Hartle & Klug GbR

To unsubscribe, e-mail:
For additional commands, email:

View raw message