Return-Path: Delivered-To: apmail-forrest-dev-archive@www.apache.org Received: (qmail 88801 invoked from network); 23 Oct 2004 05:53:07 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 23 Oct 2004 05:53:07 -0000 Received: (qmail 57852 invoked by uid 500); 23 Oct 2004 05:53:05 -0000 Delivered-To: apmail-forrest-dev-archive@forrest.apache.org Received: (qmail 57801 invoked by uid 500); 23 Oct 2004 05:53:05 -0000 Mailing-List: contact dev-help@forrest.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: dev@forrest.apache.org Delivered-To: mailing list dev@forrest.apache.org Received: (qmail 57781 invoked by uid 99); 23 Oct 2004 05:53:04 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: neutral (hermes.apache.org: local policy) Received: from [65.77.211.93] (HELO indexgeo.net) (65.77.211.93) by apache.org (qpsmtpd/0.28) with ESMTP; Fri, 22 Oct 2004 22:53:03 -0700 Received: from [192.168.1.100] (static-109.227.240.220.dsl.comindico.com.au [220.240.227.109]) (authenticated bits=0) by www2.kc.aoindustries.com (8.12.9-20030917/8.12.9) with ESMTP id i9N5qwpv031262 for ; Sat, 23 Oct 2004 00:53:00 -0500 Subject: Re: DocBook and numeric entity declaration From: David Crossley To: dev@forrest.apache.org In-Reply-To: References: <0ABB57CE-DADD-11D8-8DCA-00039385397E@medata.com> <1090396294.1666.65459.camel@ighp> <959D583A-DB23-11D8-8DCA-00039385397E@medata.com> <1090478385.1666.65952.camel@ighp> <71A6B550-DBF3-11D8-90B1-00039385397E@medata.com> <1090564098.1667.67375.camel@ighp> <78D5CBC0-E182-11D8-A85F-00039385397E@medata.com> <599A46F4-E23A-11D8-B3AB-00039385397E@medata.com> <8C2FD019-E242-11D8-B3AB-00039385397E@medata.com> <410A8D7B.9030203@brondsema.net> <410D53A3.8060702@brondsema.net> <65E128D6-E4B7-11D8-BA09-00039385397E@medata.com> <41101B0D.9040408@brondsema.net> <1EC1B9E7-2193-11D9-9F59-00039385397E@medata.com> <41755! ! 5E7.7080501@che-che.com> <7597D3B7-23A9-11D9-8F30-00039385397E@medata.com> <1098423897.22786.56.camel@ighp> Content-Type: text/plain Organization: Message-Id: <1098510706.22785.3238.camel@ighp> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 23 Oct 2004 15:52:08 +1000 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N Clay Leeds wrote: > David Crossley wrote: > > Clay Leeds wrote: > >> Changing → to → is an acceptable solution. The xml-fop > >> /forrest/ build does not error out when it tries to validate > >> 'properties.xml'. I made the change and checked it in. > >> > >> I'd also like to resolve the error in Forrest if possible, so the rest > >> of this POST deals with that. > > > > I do not see any such problem. I have a test seed site > > that includes a couple of Full DocBook examples using the > > DocBook XSL and also processes them via Forrest's default > > docbook2document XSL. I can add an example character entity > > to them → and everything works perfectly: > > 'forrest validate' is fine > > and with 'forrest run' i see the entity rendered as "->" > > as expected. > > Is it: > - just /forrest/ which doesn't render it? Everything is fine. Sorry, i should have said so above. It is important to test all situations. > - did you render xml-fop/ yesterday (after I changed it to its numeric > entity: →)? I am not using xml-fop xdocs. This is my own stuff. > - is this your own example which you added an example character entity? That is correct. > > This is my document type declaration. > > > PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" > > "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> > > > > Forrest resolves all the DTDs and *.ent properly. > > > > More below ... > > > >> I suspect the problem is related to the fact that properties.xml > >> references a dtd like this: > >> > >> > >> > >> A couple of things I note here: > >> 1. It's commented out > > > > I don't understand. How can it ever work if it is commented out? > > I suspected this may be the problem, but wasn't sure. Definitely the problem. The whole system depends on the Public Identifier, i.e. Forrest's validation, the entity resolver, and the sitemaps for Cocoon to decide which pipeline to apply to each different document type. > However, even if > it's not commented out, the docbookx.dtd file doesn't exist in that > directory, so I'm thinking it would still fail. That is why we have the Catalog Entity Resolver. Please try the suggestion below. If the resolver is failing, then you will get the wrong messages and if you are using full URLs as the System Identifier then you would see network traffic going to get the DTD on every parse. http://ngrep.sf.net/ 'ngrep dtd'. > > Remember, if you suspect issues with the catalog entity resolver > > then raise the verbosity level in src/core/context/WEB-INF/cocoon.xconf > > for the component. Then watch the messages > > when Cocoon starts and during 'forrest run'. You should see stacks > > of messages and then "Resolved public: ..." when the forrest catalog > > finds each DTD and *.ent file. > > --David > > Actually, I didn't remember. Glad you brought that up. I am going to enhance/create FAQs for this. > BTW, perhaps > forrest could be improved with a note in the output/BUILD FAILED > indicating this tip. If we can, yes. -- David Crossley