Re: RFC Implementation of SGML/XML Proposal for LSB in Debian
>
> Below is an RFC for the implementation of the SGML/XML Proposal for the LSB
> (version 0.3) in Debian. I've send this to several mailing list to give it
> broad attention, but please keep all the further discussion on debian-sgml.
> All affected package maintainers please subscribe to debian-sgml.
>
> The complete proposal can be found at
>
> http://dulug.duke.edu/~mark/debian/sgml/bischoff/
BTW, the sgml component of the proposal is also part if the LSB 0.4.1 RFC.
The content is the same as the copy above, but the rationale is not included.
LSB is taking comments until Wednesday January 24th, 2001. It's here:
http://www.linuxbase.org/spec/spec/lsbsgml.html
Here are my comments.
XSL Stylesheet Comment
------------------
-- We need a mechanism for docbook-related XSL stylesheets to refer to the main
DocBook XSL Stylesheet (dbxsl) distribution.
Example: DocBook Website Stylesheets reference sheets from the dbxsl distribution.
At present we (I, anyway) do this by only allowing one version of the dbxsl to exist on a
system -- same as Adam does with the DSSSL style sheets. The difference between xsl
and dsssl is that presently there is no catalog mechanism for the xsl stylesheets, which
will make importing more difficult. Here's a basic description of the situation:
Presently the distributions sit in an nwalsh/ subdirectory of the
/usr/lib/sgml/stylesheet/docbook/[xsl or dsssl]/] stylesheet tree with the same
largely-flat layout as the upstream source, like so:
nwalsh/
common/
...
print/
html/
Note: No version numbers are in this tree --
as are suggested by the bischoff sgml/lsb proposal.
In the xsl case, I've been installing additional stylesheets into the same nwalsh/ subdir,
the result of which looks like this:
nwalsh/
common/
...
print/
html/
website/[possible versioned subdirs here]
The point:
The website stylesheets must import html/docbook.xsl from the main distribution,
which I do by a relative path:
<xsl:import href="../html/docbook.xsl"/>
This won't work with the proposed scheme, which will now have version-numbered
directories for the docbook xsl stylesheets.
What to do?
- Don't allow multiple versions of _main_ docbook-xsl-stylesheets. They really are upgrades,
making it unnecessary to do so. (Norm Walsh, upstream developer also made this point.)
- Use the /etc/alternatives system to establish links that can be configured.
The link could be top-level:
/usr/share/sgml/docbook/xsl-stylesheets <--
- Ask Norm -- Maybe a catalog mechanism for the xsl stylesheets is in the works??
-----
Directory Structure Comment:
---------------------
On the proposed directory structure -- grouped by classes of dtds rather than file function:
-Current dir structure:
/usr/[share or lib]/sgml/
dtd/
stylesheet/
entities/
-Proposed:
/usr/share/sgml/docbook/
sgml-dtd-3.1/
sgml-dtd-4.0/
xml-dtd-4.0/ (the DocBook DTD)
dsssl-stylesheets-1.54/
xsl-stylesheets-1.12/
Wouldn't a hybrid of the two make much more sense? Something like:
/usr/share/sgml/docbook/
dtd/
stylesheet/
entities/
The proposed structure looks unnecessarily messy, and harder to maintain.
Perhaps the authors of the proposal haven't encountered the xsl stylesheet
problem -- I don't see any rpms for them.
I'm going to submit this "hybrid" idea to LSB as part of their RFC, unless
someone here feels strongly that the present proposal is a better solution.
Terminology Comment
----------------
I think the proposed use of the term "SGML Application" as
Any program used to view, edit, convert, process or apply any kind of
treatment to a document written using a SGML or XML DTD.
is not a good idea.
The term is already in wide use and has a very specific meaning:
An application of SGML, or SGML application, refers to a DTD.
(For example, see http://xml.coverpages.org/gen-apps.html )
Adoption of this term will surely create mass confusion.
I suggest the term "Component" instead, as used informally by
Cees de Groot, the sgml-tools guy.
My $0.02
Mark
> 0. Introduction
>
> Currently, the SGML/XML related stuff is located under /usr/lib/sgml including
> the super catalog (which is symlinked to /etc/sgml.catalog).
>
> In the proposal this is split between /usr/share/sgml and /etc/sgml:
>
> /etc/sgml/
> Configuration files, including centralized catalogs.
>
> It includes:
> *.conf: generic configuration files
> sgml-docbook.cat, tei.cat, ...: DTD-specific centralized catalogs
> catalog: the super catalog
>
> /usr/share/sgml/
> Architecture-independent files used by SGML applications: Open
> Catalogs (not the centralized ones), DTDs, entities, stylesheets,
> and other declarative files, if any.
>
> It is organized into DTD-specific subdirectories:
> docbook/
> tei/
> html/
> debiandoc/
> ...
>
>
> 1. Transition
>
> The transition will consists of several steps:
>
> 1. setting up the new structure while retaining the old one
> 2. adapting all affected packages to use the new structure
> 3. removing the old structure
>
> In the first step each package with files under /usr/lib/sgml has to put the
> these files under both /usr/share/sgml and /usr/lib/sgml. This can be done
> either by simply putting a copy under /usr/lib/sgml or by symlinking from
> /usr/lib/sgml to /usr/share/sgml. Since we're talking about only a few MBs
> in size in total, the first solution is probably the easiest to achieve.
>
> In the second step we have to adapt each SGML application to look under the
> new structure for the SGML files. This is the most challenging part.
>
> The third step is simply removing from each affected package the files under
> /usr/lib/sgml.
>
>
> 2. Support
>
> The sgml-base package will provide support to maintain the centralized
> catalogs and the super catalog by adapting `install-catalog`. During the
> transition both the old and the new structure (w.r.t. the catalogs) will be
> supported.
>
> There will be no support for maintaining the structures themselves.
>
>
> 3. Conclusion
>
> The first thing to do is to have the sgml-base support in place. I'll also
> setup a web page with the type and status of all affected packages. With type
> is meant SGML application and/or DTD, stylesheet, etc.
>
> After that we can start working on the transition itself.
>
> --
> Ardo van Rangelrooij
> home email: ardo@debian.org
> home page: http://www.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
Senior Lecturing Fellow
111 Physics Bldg., Box 90305
Department of Physics
Duke University
Durham, NC 27708-0305
(919) 660-2504 Fax: (919) 660-2525
Reply to: