Re: status of /ust/lib/sgml -> /usr/share/sgml transition
On Thursday, September 6, Ardo van Rangelrooij wrote:
Hi Ardo,
Good to hear from you.
> I was just checking how many and which packages still have stuff installed
> under /usr/lib/sgml and we're almost there. :-)
> Can I file bug reports against these package or is it better to make them
> wishlists?
For now, I'd do wishlists at most. After a lengthy break, the
LSB-xml-sgml spec discussion/development is about to begin anew -- and
there will likely be substantial changes for the xml part. Dan
Veillard (libxml, xslt,...) & I have exchanged a few messages and
we're ready to jump start the process. Maybe even today. (I'm
currently finishing a proposal so I can get paid to manage that
process... No uploads til the proposal is finished:-))
Again, the activity will be on the lsb-xml-sgml list when it starts up
again. Note that the host for both the archives [1] and the list
posting address [2] and have changed.
There are also some issues with, or not addressed by the SGML
component of the spec that we ought to look at from the debian
perspective. Some opints are purely debian policy issues, and some are
directly connected to LSB. For example:
1. Entity References in Upstream Files (mods, dtds, ...)
Should we _always_ change the SYSTEM ids in entity definitions to
debian-specific relative paths, thereby assuming the user has no
catalog support. And when should we retain the PUBLIC ID?
Example:
In the case of the jrefentry.dtd [3], the upstream source
defines the full docbook xml dtd as the entity '%docbook' and
then references it as follows:
<!ENTITY % docbook PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
"http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd";>
%docbook;
To be on the safe side, when I packaged this dtd I changed the
SYSTEM ID to a relative path and ditched the PUBLIC ID like so:
<!ENTITY % docbook SYSTEM "../../../dtd/xml/4.1.2/docbookx.dtd">
%docbook;
As soon as I upload my packages, we'll have tr9401 catalog support
for xml docs (via saxon, xt, xalan), complete with docbook html chunking
- maybe xsltproc is there already... (But not XML catalog support
until we decide where to put everything.) Does this mean we should
assume xml document authors have installed the appropriate catalog
tools?
The arbortext catalog classes qualify for inclusion in main, but
they don't support XML Catalogs. OTOH, the Sun Resolver classes are
a definite non-free, and they do it all.
See my point? We either assume catalog support OR fix upstream
entity defs.
2. Should we** require SYSTEM entries in the local
catalogs?
Doing so would allow effective catalog usage (and hence validation)
of even FPI-free xml source docs such as the following:
Example:
<!DOCTYPE book SYSTEM
"http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd";>
(** 'we' refers to the debian-sgml-policy-hacks who actually read
messages like this one.)
And with the sgml part of the LSB spec, here's an item:
3. Centralized Catalogs [4]
Our implementation doesn't add any functionality, and the
recommended method isn't realistically implementable:
" + the centralized catalogs [are] used as central source of
information that is specific to docbook, tei, or any other DTD"[4]
the example given is:
-- sample contents of /etc/sgml/foo-1.05.cat --
CATALOG /usr/share/sgml/foo/xml-dtd-1.05/catalog
CATALOG /usr/share/sgml/foo/xsl-stylesheets-0.1/catalog
For, say, docbook-xml on debian, this'd mean we put all
"docbook-xml related" catalogs in /etc/sgml/docbook-xml.cat. But
this notion is ill-defined at best. Do catalogs from the website
package, the dsssl stylesheets, the xsl stylesheets, etc. all go
into /etc/sgml/docbook-xml.cat?
Of course, it is possible to do this sort of thing sensibly by
creating a quantity that somehow describes more general
relationships between packages (or by simply looking for a depends,
recommends, or suggests. And you guys would have to substantially
beef up the catalog-updating scripts, as well. But, all that effort
would still IMHO seem moot: catalogs (esp. xml catalogs) already
take care of these issues.
BTW, if you want to generate your own hardcopy of the lsb-sgml-spec
draft, download the sgml source and process it to your taste. [5]
4. [FYI] DTDs for Generating Valid XML Catalog Files
Finally, I collected the dtd and some test docs for the new OASIS
XML Catalog spec [6]. I also wrote a customization layer for the
catalog dtd that adds a few additional elements to provide full
support for the tr9401 catalog semantics.
The upshot being that we can now map the old tr9401 catalog entries
to xml catalog elements in a one-to-one fashion. I also generated
content models for both dtds, for the sake of comparison. See the
ME-YOU-SHOULD-READ file at the url in [7] for more info.
Back to writing...<sigh duration="excessive"/>
Mark
References:
[1] http://lists.dulug.duke.edu/mailman/listinfo/lsb-xml-sgml
[2] email: lsb-xml-sgml@dulug.duke.edu
[3] http://docbook.sourceforge.net/release/jrefentry/1.1/jrefentry.dtd
[4] http://people.debian.org/~mrj/lsb-sgmlspec_cvs20010828/sgmlr003.html
[5] http://www.linuxbase.org/spec/gLSB/sgmlspec/sgmlspec.sgml
[6] http://www.oasis-open.org/committees/entity/spec.html
[7] http://people.debian.org/~mrj/oasis/catalog/xml/
> Hi,
>
> I was just checking how many and which packages still have stuff installed
> under /usr/lib/sgml and we're almost there. :-) The 'Debian package contents
> search results' was only a single page short.
>
> The following packages still need to move stuff:
>
> cygnus-stylesheets
> festival
> jade
> opensp
> psgml
> sgml-data
> sgmltools-lite
> sp
> xbel
>
> Note that not every package has 'real' stuff in /usr/lib/sgml; e.g. sgml-data
> only has some symlinks there (for legacy support?).
>
> To prevent an even more complex legacy catalog handling in sgml-base I think
> it's best to move over to /usr/share/sgml and the old catalog stuff removed
> from sgml-base before we introduce the next change in catalog managing (see
> e.g. bugs #88008 and #88010). We should then also incorporate XML catalog
> support (see another thread on this mailing list).
>
> Can I file bug reports against these package or is it better to make them
> wishlists? The policy we're implementing here is not official yet.
>
> Thanks,
> Ardo
> --
> Ardo van Rangelrooij
> home email: ardo@debian.org
> home page: http://people.debian.org/~ardo
> PGP fp: 3B 1F 21 72 00 5C 3A 73 7F 72 DF D9 90 78 47 F9
>
>
> --
> To UNSUBSCRIBE, email to debian-sgml-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
--
_____________________________________
Mark Johnson <mark@duke.edu>
Debian SGML <mrj@debian.org>
Home Page: <http://dulug.duke.edu/~mark/>
GPG fp: 50DF A22D 5119 3485 E9E4 89B2 BCBC B2C8 2BE2 FE81
Reply to: