cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Crossley <cross...@indexgeo.com.au>
Subject Re: Resolution/validation woes
Date Thu, 03 Jan 2002 01:00:34 GMT
Hi Gianugo, i had the beginnings of a new Cocoon Sample
to show how to use the Simplified DocBook DTD. So i have
now committed that to CVS to give you a kick-start.

You will need to add a "local-catalog" parameter to your
webapp/cocoon.xconf (see attached diff).

You will also need a corresponding "OASIS catalog" file to
define the location of the sdocbook.dtd ... see the doco at
http://xml.apache.org/cocoon/userdocs/concepts/catalog.html#config

I have not yet hooked up the new Sample because it still
needs some more work to explain this local configuration.
However, it should be enough to get you going at
http://localhost:8080/cocoon/sdocbook-demo
--David

David Crossley wrote:
> Excuse me, but RTFM must apply here :-)
> This is the prime example of why we need the
> Catalog Entity Resolver for Cocoon, and why we
> have been working hard to get it implemented.
> Please see the Cocoon docs at
> http://xml.apache.org/cocoon/userdocs/concepts/catalog.html
> 
> It even provides an example of how to configure it
> for the Simplified DocBook DTD.
> 
> As Berin says, the parser needs to find the DTD whether
> it it set to do validation or not. Hacking the XML source
> to remove the DTD declaration is NOT the way to go.
> We have the perfect solution already available in Cocoon.
> enjoy, David Crossley
> 
> Gianugo Rabellino wrote:
> > Berin Loritsch wrote:
> >  Gianugo Rabellino wrote:
> > >> I always try to avoid validation, but this time I have to: 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
> > >>
> > >> <!DOCTYPE article SYSTEM "sdocbook.dtd">
> > >>
> > >> directive. This caused my Cocoon to fail with a 
> > >> ResourceNotFoundException on the missing DTD file.
> > 
> > > This has nothing to do with Validation, or a Cocoon setting.  This has
> > > everything to do with Xerces, or whatever your parser is.  The fact is
> > > that Xerces will read the DTD if the DocType header is placed in the
> > > document everytime.  It does this for entity resolution in your documents.
> > 
> > OK, that's exactly what I knew. But I also thought that the parser was 
> > not meant to choke and give up parsing if (in non-validating mode) the 
> > DTD could not be found. This is the behaviour I expect and that I 
> > strongly recall I encountered before, am I that wrong?
> > 
> > > If you choose not to perform validation (the default), the DTD is still
> > > read, although only the entity declarations are used.  Now, there *might*
> > > be something in the way we create Parser objects that we need to change
> > > so that they use the EntityResolver (i.e. catalog) for us.
> > 
> > That might help.
> > 
> > > If you want to completely ignore all DTD/Schema directives, do not supply
> > > a DocType header!
> > 
> > OK, now we have a chicken and egg problem. I would gladly use a 
> > stylesheet to strip the DTD part using the xsl:copy-of trick, but 
> > actually I can't because my document isn't parsed so it cannot be 
> > transformed :) This sounds pretty weird to me, I'm not going to resort 
> > to String.replace() for this. I have to find a way out, and I strongly 
> > suspect that I'm not the only one...
> > 
> > I'll check out the docs (actually I already had a look at the Xerces 
> > FAQs, and it seems that the only occasion when an error is thrown is 
> > with a DTD declared but not found in validating mode). Thanks for now.
> > 
> > Ciao,
> > 
> > -- 
> > Gianugo


Mime
View raw message