forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Wheller <>
Subject Re: Catalog for Docbook Plugin
Date Thu, 28 Oct 2004 08:27:04 GMT
On Thursday 28 October 2004 09:44, David Crossley wrote:
> > To answer the question about rewriteSystem and rewriteURI.
> > Instead of having a large number of catalog entries I have used
> > rewriteSystem and rewriteURI to map the first part of the the reference
> > to a different prefix. This way I can map many files located in the same
> > place with a single catalog entry. It makes life easier, especially with
> > the XSL's. People can call different XSL's to do different things in
> > Docbook  e.g docbook.xsl for normal transform, profile.xsl for
> > transformations that are profiled. chunk.xsl to get write a long document
> > to many files.
> Yes that is good. Sorry to make you explain that. I should
> be more careful with words. I mean the difference between
> "rewriteSystem" and "rewriteURI", not between those and
> Public Identifiers.

No my fault, I should have read it again.

> > I call the nextCatalog only to solve the PUBLIC ID's. Instead of writing
> > them into my own file as we have with catalog.xcat I just call them and
> > use the catalog of the package. This way, as an example, I just need to
> > add one more nextCatalog when Docbook 4.4 becomes official.
> Damn, crossed-wires again. 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 

<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN"

Resolver can prefer "public" or "system," my catalog has @prefer

I want an easy way to rewriteSystem prefix ""

So it will be

Ross has taken charge of doing FOR-
This is to replace 
"file:///path/to/forrest" with
during the build

The catalog.xml provided by most packages does not map the systemId it maps 
only the publicId. It will try SYSTEM and fallback to public. If system is a 
URL it will go look there. So I rewrite the prefix to be local.

To resolve a "URI" reference, say to the stylesheets. This is when there is no 
DocTypeDecl with publicId or systemId to resolve from.

For example a stylesheet may call another. Using the same URI as that known in 
the public domain is a good idea, but not practical since it means network 
operations that slow things down. Using a "hardcoded path" may result in the 
system breaking when paths change, like between when you move to a new 
computer. With this, everyone can use the public knowledge URI and map to a 
local resource by defining it is ONE place. The actual URI does not need to 
exist, as is the case with the forrest examples.

Again, since my catalog has @xml:base

I can dynamically construct the full path during processing by using the 
So it will be

Unfortunately the Java Resolver does not support simple systemIds
<uri name="docbook.xsl" uri="stylesheets/1.66.1/docbook.xsl"/>

Hope that helps explain the difference.

> > Oh, and I can rewrite***
> > prefixes to the local location. I considered doing this for catalog.xcat,
> > but decided to leave it. It ain't broken, so don't fix it.
> The Public Identifiers that we are currently using in
> our core catalogs work beautifully.

yes. no need to fiddle, unless you want to make neat and reduce overhead 

Sean Wheller
Technical Author

View raw message