Re: docbook-xml & centralized catalogs
Mark Johnson <mark@phy.duke.edu> writes:
> 2. We need to name it.
> ----------------
> The spec says to call it
> xml-docbook-4.1.cat
> but there are a number of 4.X dtds referred to here and there. And the X
> varies slightly.
You are referring in this case to the catalog snippet needed for the
docbook-xml derivitives, using the docbook-xml file?
[...]
> Packages which depend on the central-catalog-bringing dtd automatically
> have their catalog data put in the centralized catalog of the dtd
> package on which they depend. AND - here's the tricky part - The
> subpackages should NOT have to know the name of the centralized
> catalog!! Got that?
No, I'm confused. I suppose if I look at docbook-simplified and the
stuff you do in there it may illuminate me?
I wish you could get me on IRC and we could talk. I'm sometimes on
#debian-boot of Debian IRC network (and am on there now). You'd have
to /msg me a few time.
I have an alternative proposal:
diverge even more from the spec, and leave the catalog files in the
dir with the materials, e.g.:
/usr/share/sgml/dtd/docbook/docbook-xml/4.1.7/catalog
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
or whatever if I'm wrong here
I think leaving the catalog files spread around in same dir with the
SGML/XML materials such as entities and DTDs is going to be a lot
easier:
(a) it means we can often use catalog snippets from upstream with
minor modifications
(b) the /etc/sgml/catalog CATALOG directive is the place that
it needs to directly know the dir location, rather than every entry
in the catalog files themselves
(c) the issue queried by Mark before (using a generalized "whatever
is the current 4.1 docbook-xml catalog) can be solved by the
docbook-xml/{4.1,4} symlinks technique
Thoughts? I know it's a little sketchy feeling to be moving catalogs
into the dir with entities and dtds, but I think it really is easier
to manage, closer to upstream, etc. And lets face it, upstream SGML
catalogs for specific SGML/XML packages are not really user
configuration files at all anyhow, are they?
--
.....Adam Di Carlo....adam@onShore.com.....<URL:http://www.onShore.com/>
Reply to: