forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Wheller <s...@inwords.co.za>
Subject Re: Catalog for Docbook Plugin
Date Thu, 28 Oct 2004 09:57:03 GMT
On Thursday 28 October 2004 11:35, 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. 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. 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.

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

>
> > 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 :-(

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

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

Mime
View raw message