forrest-dev mailing list archives

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

> I have chosen to use nextCatalog and 
> not have to copy paste from the package catalog.xml.
>
> > 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.
> 
> Yes, I noticed, but you have also had to copy stuff already done once. My 
> method just uses what has already been done.

The Forrest core catalogs have grown like topsy.
Over the years people a have added quick copies
and not used nextCatalog. A while ago Dave dived in
and tidied it up a lot. Probably needs more tidy
and of course later we will move some of it out to
plugins.

> I like this because I can 
> quickly and easily create a catalog that may resolve many Doc Types. For 
> example look in 
> forrestcore/src/core/context/resources/schema/
> 
> There are so many catalogs, when you could just have one driver in the schema 
> folder and then have one catalog for each of the packages (this is shipped 
> anyway with the package). I think it better to keep catalog and package 
> together. For example the Apache DTD's.

I agree. We should tidy whatever is left in the core.

> > 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.
> 
> Yes, but is it better than what I have done. It is not wrong or right, it's 
> just a matter of convenience.
> The Docbook plug-in will have many DTD's
> Docbook Plugin V0.1
>   This plugin provides full support for:
>   - Docbook XML V4.1.2, V4.2, V4.3
>       - EBNF Forms (under consideration)
>       - MathML (under consideration)
>       - SVG (under consideration)
>   - Simplied Docbook V1.0
>   - Docbook Slides V3.3.1
> 
> This could be a very long catalog if I don't use this method and will only 
> grow as new versions arrive i.e. DB V4.4, sDB V1.1.

Are you saying that it is a matter of efficiency?
The resolver will find your systemId match up-front
and not go loading the next catalog to find the PublicId.
Although i suppose that once the catalog is loaded
then it is already there for the next document parse.

> > > Normally,
> > > <!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN"
> > >                          "http://www.docbook.org/xml/4.3/docbookx.dtd">
> > >                                                       /\
> > >                                                        |
> > >                                               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
> > > "http://www.docbook.org/xml/4.3/"
> > >
> > > So it will be
> > > "file:///path/to/forrest/plugins/docbook/resources/$rewritePrefix/docbook
> > >x.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.
> 
> Yes, I just use it as fallback. The sooner it resolves, the faster.

Aha. (I just now read down to here.)

> > > 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.
> > http://forrest.apache.org/docs/validation.html#catalog
> > http://cocoon.apache.org/2.1/userdocs/concepts/catalog.html
> >
> > I am so pleased to see other people keen on the
> > powers of the entity resolver.
> 
> Sorry, glad you understand.
>
> > > 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.xs
> > >l"
> > >
> > > 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.
> > http://xml.apache.org/commons/
> 
> Not good :-(

Mine either, but often stumbling about and making
a start gets other people interested.

> > > 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.
> 
> Do you see the benefit above?

I think so. I will go mull it over with some
late-night card game and wine.

-- 
David Crossley


Mime
View raw message