Mailing-List: contact dev-help@forrest.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@forrest.apache.org
Received-SPF: neutral (hermes.apache.org: local policy)
From: Sean Wheller <sean@inwords.co.za>
Reply-To: sean@inwords.co.za
Organization: In Words
To: dev@forrest.apache.org
Subject: Re: doctype Public Identifier is crucial (Was: Catalog for Docbook
 Plugin)
Date: Fri, 29 Oct 2004 09:25:05 +0200
User-Agent: KMail/1.6.2
References: <200410260917.15849.sean@inwords.co.za>
 <1098959245.22785.28572.camel@ighp> <1099012353.22790.33459.camel@ighp>
In-Reply-To: <1099012353.22790.33459.camel@ighp>
MIME-Version: 1.0
Content-Disposition: inline
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <200410290925.05307.sean@inwords.co.za>

On Friday 29 October 2004 03:12, David Crossley wrote:
> David Crossley wrote:
> > Sean Wheller wrote:
> > > David Crossley wrote:
> > > > Sean Wheller wrote:
> > > > > David Crossley wrote:
> > > > > > ...Looking back at the example
> > > > > > catalog that you showed, i wondered why you were using
> > > > > > rewriteSystem for the DocBook DTDs and then *also*
> > > > > > doing the nextCatalog. It would only need the latter.
> > > > >
> > > > > To resolve DTD URL "system" ID to local
> > > >
> > > > I would think that it would find it in the nextCatalog
> > > > anyway, via its publicId.
> > >
> > > Yes, it will if the publicId is defined.
> >
> > If there is no publicIdentifier in the documents
> > then the guts of Forrest aren't going to know what
> > type of document it is.

An XML document does not have to contain a DocTypeDecl.

>
> Just making absolutely sure that you did not
> miss this comment.
>
> http://forrest.apache.org/docs/cap.html
> "SourceTypeAction (content aware pipelines)"
>
> Forrest applies different processing depending on the
> document type. This is determined by the SourceTypeAction
> in the sitemap. Its primary way of determining the
> document type of an xml source is to use the Public Identifier.

Yes, I saw that and have no problem with SourceTypeAction. 

I don't see how SourceTypeAction relates to the catalog resolver, does it?

Seems to me that cocoon uses sitemaps as interpretted code.
The "map:action" defines a name and java class to use.
The "sourcetype" associates a logical name with "document-declaration."

When the file is parsed cocoon can id the "sourcetype" without using resolver.
When it comes time to use it such as in "map:transform" under a "map:when" the 
logic is that cocoon does not have to use the catalog and immediately knows 
which "sourcetype" exists and what to do with it. The catalog is ignored in 
the logic.

I don't fully agree with this logic since there are times when a document uses 
a SYSTEM and not PUBLIC identifier, but this can be fixed by adding a new 
sourcetype to the sitemap.

-- 
Sean Wheller
Technical Author
sean@inwords.co.za
http://www.inwords.co.za