Martin
Thanks for this - I have also had problems trying to
process documents with DocBook - it is a large DTD
and the stylesheets supplied (assuming you do not
and the stylesheets supplied (assuming you do not
write your own) are also huge - even without using
cinclude.
I knwo for myself that I really do not understand how
caching works in Cocoon, and most of your questions
and suggestions below are pretty much Greek to me (!)
- is there any way you could perhaps consider writing
up a *simple* guide* to dealing this type of issue &
posting it on the wiki - or is there already such a beast
readily available?
Thanks
Derek
>>> [EMAIL PROTECTED] 26/02/2003 10:16:37 >>>
"Josema Alonso" <[EMAIL PROTECTED]> writes:
> Replying to myself but still haven't found a good explanation...
>
> The *.news.xml docs I mentioned in my previous message are Docbook articles.
> All of them have the doctype declaration for the Docbook article DTD:
> <!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
> "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
>
> I removed the declaration and everything went fine.
>
> I thought that maybe it was trying to validate the articles and retrieving
> the DTD remotely, but I switched to a local copy of the DTD and the problem
> is still the same.
>
> By now, I have removed the doctype declarations, but this is just a quick
> workaround. I do not know what's going on...still investigating...
How long does the FileGenerator need for each of the documents?
I guess the cinclude generator needs slightly longer than the sum
of the FileGenerators execution times. A xml parser will read
all of the DTD, even if it is not validating. Are you sure, you are
reading a local copy of the DTD?
Have a look at org.apache.cocoon.components.resolver.ResolverImpl.
Did you add the Docbook to the catalog? Proper entity resolving can really
boost cocoon performance.
How large is the Docbook-DTD? Maybe a caching EntityResolver helps.
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
>>> [EMAIL PROTECTED] 26/02/2003 10:16:37 >>>
"Josema Alonso" <[EMAIL PROTECTED]> writes:
> Replying to myself but still haven't found a good explanation...
>
> The *.news.xml docs I mentioned in my previous message are Docbook articles.
> All of them have the doctype declaration for the Docbook article DTD:
> <!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
> "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
>
> I removed the declaration and everything went fine.
>
> I thought that maybe it was trying to validate the articles and retrieving
> the DTD remotely, but I switched to a local copy of the DTD and the problem
> is still the same.
>
> By now, I have removed the doctype declarations, but this is just a quick
> workaround. I do not know what's going on...still investigating...
How long does the FileGenerator need for each of the documents?
I guess the cinclude generator needs slightly longer than the sum
of the FileGenerators execution times. A xml parser will read
all of the DTD, even if it is not validating. Are you sure, you are
reading a local copy of the DTD?
Have a look at org.apache.cocoon.components.resolver.ResolverImpl.
Did you add the Docbook to the catalog? Proper entity resolving can really
boost cocoon performance.
How large is the Docbook-DTD? Maybe a caching EntityResolver helps.
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
This message has been scanned for viruses and dangerous content by
MailScanner, and is believed to be clean.
"The CSIR exercises no editorial control over E-mail messages and/or
attachments thereto/links referred to therein originating in the
organisation and the views in this message/attachments thereto are
therefore not necessarily those of the CSIR and/or its employees.
The sender of this e-mail is, moreover, in terms of the CSIR's Conditions
of Service, subject to compliance with the CSIR's internal E-mail and
Internet Policy."
