Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Content-Type: text/plain;
  charset="iso-8859-1"
From: David Crossley <crossley@indexgeo.com.au>
Reply-To: crossley@indexgeo.com.au
To: cocoon-dev@xml.apache.org
Subject: Re: Resolution/validation woes
Date: Thu, 3 Jan 2002 19:15:34 +1100
References: <3C33582E.9000100@rabellino.it>
In-Reply-To: <3C33582E.9000100@rabellino.it>
MIME-Version: 1.0
Message-Id: <02010319153500.01356@igacer>
Content-Transfer-Encoding: 8bit

Gianugo Rabellino wrote:
> Looks like it's time to confess how much my hate for DTDs and validation 
> in general brought me to a deep ignorance and to what seems to be a dead 
> end alley.
> 
> I always try to avoid validation, but this time I have to:

I am amazed that you do without XML validation. It is all too
easy to get a broken XML instance which could wreak havoc
for your application. Also the user will end up with some
competely unintelligible exception messages. XML instances
are supposed to be reliable, so that any downstream application
can depend on them.

We validate all of our XML documents before they ever get to
Cocoon (using an external tool). To do this we need the
Document Type Declaration in the XML instance. And yes,
that external tool also uses an entity resolver to find the DTD.

> while playing 
> with a pretty cool DocBook add-on for M$ Word (you might want to check 
> it out at http://www.yawcpro.com: it's closed-source yet it has a free 
> that does all that is needed to me) I'm facing the fact that the 
> software saves its documents with a
> 
> <!DOCUMENT article SYSTEM "sdocbook.dtd">

Your XML creation tool should really use a proper
Public Identifier for this Document Type Declaration.
See the Cocoon sample "sdocbook-demo" for an example.
If you are stuck with the above declaration, then i describe
a workaround solution below.

> directive. This caused my Cocoon to fail with a 
> ResourceNotFoundException on the missing DTD file.
> 
> Now... I tried to turn validation off in cocoon.xconf. No luck. I tried 
> then to resort to the entity resolver by adding the line
> 
> SYSTEM "sdocbook.dtd" "sdocbook.dtd"
> 
> to the end of resources/entities/catalog. No way: the little boy still 
> insists to have its private copy of sdocbook.dtd in the same directory.

That is because the alternative system identifier that you
have mapped here is to exactly the same URI.
This catalog entry should suffice:
SYSTEM "sdocbook.dtd" "/usr/local/sgml/docbook/simple/sdocbook.dtd"

Of course you must have the relevant Simplified DocBook DTD
at that location, for the DTD version that you are using. This is 
one important reason to use Public Identifiers rather than System
Identifiers - you can properly specify the appropriate DTD version.

As explained in other email and the Cocoon docs,
the parser will need to resolve and read the DTD whether
you have "validate" set to either true or false. Among other
things, it needs to find any character entity sets that might
be used by this document.

> Now for the question: how on earth am I supposed to tell to the parser 
> to simply *ignore* any DTD/Schema directive (or to ignore any error 
> coming from suche Handlers)? If this is not possible, how does the 
> catalog resolution work (i.e. where do I start in debugging it apart 
> from CocoonServlet :))?

I trust that my earlier reply in this thread will help you to
properly process your XML instances without hacks.
--David Crossley

> Ciao,
> 
> -- 
> Gianugo

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org