forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Crossley <>
Subject Re: Catalog for Docbook Plugin
Date Thu, 28 Oct 2004 09:35:17 GMT
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.

With the Forrest core entity resolver we have been totally
using the Public Identifiers for everything. That way the
System Identifier can be anything - we don't care.

It seems that you have a different approach. Is it is possible
to continue using the PublicId approach? Just to be consistent
throughout Forrest. However, perhaps there are good reasons
for changing to use systemIds.

> Normally,
> <!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN"
>                          "">
> 							/\
> 							 |
> 						THIS PART
> Resolver can prefer "public" or "system," my catalog has @prefer
> <group
> 	prefer="system"
> 	xml:base="file:///path/to/forrest/plugins/docbook/resources/">
> I want an easy way to rewriteSystem prefix ""
> So it will be
> "file:///path/to/forrest/plugins/docbook/resources/$rewritePrefix/docbookx.dtd"
> Ross has taken charge of doing FOR-
> This is to replace 
> "file:///path/to/forrest" with
> "file:///`pwd`/plugins/docbook/resources/
> 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.

We have "prefer public". The resolver tries to find a match
for the PublicId then falls back to the systemId.

> 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.

Yep. You are preaching to the converted here.

I am so pleased to see other people keen on the
powers of the entity resolver.

> Again, since my catalog has @xml:base
> <group
> 	prefer="system"
> 	xml:base="file:///path/to/forrest/plugins/docbook/resources/">
> I can dynamically construct the full path during processing by using the 
> catalog.
> So it will be
> "file:///path/to/forrest/plugins/docbook/resources/$rewriteUri/docbook.xsl"
> Unfortunately the Java Resolver does not support simple systemIds
> <uri name="docbook.xsl" uri="stylesheets/1.66.1/docbook.xsl"/>

How's your Java skills? The code is at Apache XML Commons.

> Hope that helps explain the difference.

Even if we get wires crossed and over-explain things
to each other, good understanding and consensus is gained.

> > > 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 later.

Well i am still not seeing the benefits over the current
publicId approach. I grant that there will be certain
situations where systemId mapping will be necessary.

David Crossley

View raw message