RE: docbook-xml42, docbook-xsl, xmlto (RE: Pending package status (09 May 2003))

["Andreas" <news dot Andreas at gmx dot net>]

Hello Peter,

thanks a lot for your interesting feedback. I am looking forward to become a
wiser and better person with this thread :)

Don't know if I caught everything. I am relatively new to xml & co and very
interested in cygwin. I wrote a few docbook documents but unfortunately
there are no tools in the main cygwin repository to process them. And I
definitely think it should be supported soon.

<very_enthusiastic>
So lets form a docbook on cygwin SIG and start the discussion with a 'more
open and generally useful packaging and direcory standard'...
</very_enthusiastic>

You propose a different directory structure for stylesheets and schema types
as a summary of your posting. Furthermore you recommend a central master
catalog (version independent) hosted in /etc/xml (or /etc/sgml) that
delegates to the resource-specific catalogs that are updated with each
version of a package. A package shall contain only one resource. Is this
right?

Regards,
Andreas

> This posting is a bit longwinded, but I promise that you'll be a wiser
> and better person after reading it ;)
>
> I'd like to encourage you to think long and hard about the package,
> directory, and catalog structure for XML on Cygwin. It would be a big
> mistake to settle on something merely because it 'works for me'. The
> complexity of the problem is similar to the complexity of the TeX
> directory structure, or the structure of standard include and library
> files.
>
> From a strictly Cygwin-documentation centered packaging view, it would
> be OK just to decide on something. But that would render the package
> almost useless for anything else, and also more difficult than
> neccessary to maintain.
>
> If we make the packaging and direcory standard more open and generally
> useful, there will be more contributions to XML releated packages for
> Cygwin.
>
> My primary use of Cygwin is for document processing. I have the
> following requirements for a package and directory layout:
>
> - It must be suitable for a variety of document types (DocBook, XHTML,
>   TEI, XBRL, UBL, etc.)
>
> - It must be suitable for various schema types (DTD, WSD, RNG, etc.)
>
> - It must be easy to add new upstreams releases
>
> - It must never break past releases; documents outlive the processing
>   system
>
> - It must be easy to add local customization of 'standard' document
>   types and stylesheets
>
> - Extrapolation should be obvious, different people should be likely
>   to place any specific resource in the same directory
>
> - It must be suitable for use with a diversity of SGML and XML tools,
>   not just Cygwin packages
>
> - It must play nice with SGML Open Catalog as well as XML catalog
>
> - It must play nice with the natives, e.g. Windows application that
>   expect a drive letter in system identifiers
>
> So what are the options, are there already something available that
> can be adopted by Cygwin?
>
> It used to take a lot of esoteric knowledge to set up a SGML or XML
> tool chain. Witness Eric Raymond cry for help, only three years ago
> [1].
>
> The widespread acceptance and use of DocBook in the open source
> community started when SGML-Tools [2] switched from LinuxDoc to
> DocBook back in 1998 [3].
>
> At that time, there were a lot of discussion about a 'directory
> standard for SGML components' and standard ways of maintaining SGML
> entity resolution. You can follow one of the threads starting at
> [4], and you can see the proposal at [5].
>
> This proposal is the basis of what later became a part of FHS [6] and
> a proposed addendum to LSB. The latest proposal to LSB wrt. a
> directory layout for SGML is here [7].
>
> To the extent that XML is a subset of SGML, this proposal can also be
> used for XML. But XML is no longer a subset of SGML. The discussion
> about what a directory standard for XML resources should look like
> started around here [8], and pops up again now and then [9].
>
> Some of the issues at stake in the discussion:
>
> - Packaging centered vs. resource centered organization
>
> - Various differences between SGML and XML
>
> - Specifically, whether canonical URLs are suitable system identifiers
>   for XML resources
>
> Currently, work on the SGML/XML addendum for LSB seem to have stalled.
>
> There has once before been a proposal for a set of Cygwin
> DocBook/TEI/SGML/you-name-it packages [10]. I had a few reservations
> about those pacakages, mainly that too many different resources were
> bundled per package, and that it would be difficult for different
> versions of stylesheets to co-exist [11].
>
> Anyway, the current proposed SGML addendum for LSB looks like this
> (all catalogs are SGML Open catalogs):
>
> /etc/sgml/
>   catalog              -- super catalog points to centralized catalogs
>                           using CATALOG or DELEGATE
>   sgml-docbook.cat
>   sgml-docbook-3.1.cat
>   sgml-docbook-4.0.cat -- DTD-specific centralized catalogs point to
>                           resource-specific catalogs using CATALOG or
>                           DELEGATE
>   xml-docbook-4.0.cat
>   tei.cat
>   ...
> /usr/share/sgml/
>   sgml-iso-entities-8879.1986/
>   xml-iso-entities-8879.1986/
>   jade-1.2.1/
>   openjade-1.3/
>   docbook/
>     sgml-dtd-3.1/
>       catalog
>       ...
>     sgml-dtd-4.0/
>       catalog
>       ...
>     xml-dtd-4.0/
>       catalog          -- resource-specific catalog
>       ...
>     dsssl-stylesheets-1.54/
>       catalog
>     xsl-stylesheets-1.12/
>       catalog
>     kde-customization-0.1/
>       catalog
>     ...
>   tei/
>   html/
>   ..
>
> I've proposed a directory standard with a resource centered
> organization [12]. It makes a lot of sense to have a resource centered
> organization of XML resources if you consider that all XML resources
> worth using have a 'canonical URL' (in addition to a Formal Public
> Identifier). It is a no-brainer to map the the canonical URL to the
> local file system which becomes, in effect, a cache.
>
> The location and name of the master catalog should probably be
> '/etc/xml/catalog', since this is what libxml2 expects by default.
>
> SGML Open catalogs should be added in parallel to XML catalogs for
> applications that don't understand XML Catalog, e.g. emacs+psgml.
>
> I have not yet decided how best to bridge the gap between one-root
> filesystems (Cygwin, Unix) and multi-root filesystems (Windows drive
> letters). But if everything can be kept on one volume, all paths can
> be relative to the master catalog. Forward slashes in pathnames are
> not a problem for recent versions of Windows.
>
> Anyway, it looks like this:
>
> $XML_BASE_DIR/        -- /usr/share/xml by default
>   catalog.xml         -- master catalog that delegates public, uri,
>                          and system identifiers to catalogs below
>   docbook.sourceforge.net/
>     release/
>       xsl/
>         catalog.xml   -- rewrites reference to specific version
>         1.48/
>         1.55.0/
>           ...
>         ...
>   www.magnus.dk/      -- local resources for magnus
>     docbook/          -- local costumization of docbook
>       xml/
>         catalog.xml   -- delegates to version specific catalog
>         1.0/
>           catalog.xml -- version specific catalog
>           ...
>         1.1/
>         ...
>       xsl/            -- generally useful local xsl customization
>         ...
>   www.oasis-open.org/
>     committees/
>       entity/
>         release/
>           1.0/
>             catalog.dtd -- nice to have around when editing
>                            XML catalogs
>             ...
>     docbook/
>       xml/
>         catalog.xml   -- delegates to version specific catalog
>         configerror.txt
>         ebnf/
>           ...
>         htmlforms/
>           ...
>         mathml/
>           ...
>         simple/
>           ...
>         svg/
>           ...
>         4.1.2/
>           catalog.xml -- version specific catalog
>           ...
>         4.2/
>           ...
>       xmlcharent/
>         ...
>   www.w3.org/
>     TR/
>       html4/
>         ...
>       xhtml1/
>         ...
>       MathML2/
>         ...
>   www.you-get-the-idea.com/
>     ...
>
> Each package should contain one version of one resource, e.g. DocBook XML
> 4.2
> or DocBook XSLT 1.61.0. There shouldn't be any version dependent
> delegation
> in the central catalog; this way, only when a completely new resource is
> added, an entry in the central catalog must be added. Each time a new
> version
> of a resource is added, a new entry in the resource-specific
> catalog must be
> added.
>
> [1]  http://sources.redhat.com/ml/docbook-tools-discuss/2000/msg00202.html
> [2]  http://www.sgmltools.org/
> [3]
> http://groups.google.com/groups?selm=6gggba%244nn%241%40evrl.xs4all.nl
> [4]  http://www.via.ecp.fr/via/ml/sgml-tools/199804/msg00048.html
> [5]  http://www.sgmltools.org/docs/sgml-dir-standard/t01.html
> [6]  http://www.pathname.com/fhs/2.2/
> [7]  http://people.debian.org/~mrj/lsb-sgmlspec_cvs20020308/index.html
> [8]
> https://lists.dulug.duke.edu/pipermail/lsb-xml-sgml/2001-May/000001.html
> [9]
> https://lists.dulug.duke.edu/pipermail/lsb-xml-sgml/2003-January/0
> 00289.html
> [10] http://sources.redhat.com/ml/cygwin-apps/2002-05/msg00169.html
> [11] http://sources.redhat.com/ml/cygwin-apps/2002-05/msg00222.html
> [12]
> http://lists.oasis-open.org/archives/docbook-apps/200210/msg00038.html
>
>
> kind regards and thanks for your patience,
> --
>       \|/
>      <@ @>         Peter Ring
> +-oOO-(_)-OOo---------------------------
> |         Address  Ceresvej 16, st.
> |                  DK-1863 Frederiksberg C
> |         Phone    +45 3331 4216
> |         EMail    pri@ddf.dk
>
>
> -----Original Message-----
> From: cygwin-apps-owner@cygwin.com
> [mailto:cygwin-apps-owner@cygwin.com]On Behalf Of Marcel Telka
> Sent: 16. maj 2003 18:40
> To: Andreas
> Cc: cygwin-apps@cygwin.com
> Subject: Re: docbook-xml42, docbook-xsl, xmlto (RE: Pending package
> status (09 May 2003))
>
>
>
> On 2003.05.16 18:13, Andreas wrote:
> > > > have different versions installed. What do you think about a
> > structure
> > > > like:
> > > > /usr/share/docbook/dtd/{VERSION}
> > > > /usr/share/docbook/xsl/{VERSION}
> > >
> > > This directory structure looks good for me with one exception, xsl
> > not
> > > versioned, so:
> > > /usr/share/docbook/dtd/4.2
> > > /usr/share/docbook/xsl
> > >
> > > If this gets some votes (and voices) I'll change the structure in
> > the
> > > next package releases.
> >
> > I just had the impression that the dir structure at the moment will
> > end up
> > in a very big /usr/share in the future. But other packages will do.
>
> /usr/bin is very big now and there is no problem :-).
>
> Common practice is to place architecture-independent data into
> /usr/share/<package> directory. My current docbook packages follows
> this practice.
>
> > Is
> > there
> > a recommended way to do?
>
> FHS?
>
> >
> > > > How would these structure fit for the catalog file? Does it imply
> > to
> > > > have
> > > > one centralized catalog file that is updated each time a dtd
> > package
> > > > is
> > > > (de)installed?
> > >
> > > Where is the problem? One centralized catalog file /etc/xml/catalog
> > > looks good for me (as it is done now).
> >
> > Hmmm, thaks for pointing this out ;) Overlooked it somehow. And this
> > will be
> > maintained if other dtd packages will be installed?
>
> AFAICT, yes.
>
> >
> > BTW I just checked the xmlto site and a newer version is released on
> > May
> > 09th.
>
> Yes, I know. There is also new XSL package (1.61.0) available. If I get
> some free time I'll package it...
>
> >
> > At the moment I try to tie a passivetex package (size is ~1.3M).
>
> Great. I'm newbie in TeX stuff. My attempt to install passivetex and
> xmltex was not successful... :-(
>
> > Unfortunately I don´t have server access to provide that package for
>
> What about using some free service, like http://www.20megsfree.com/ ?
>
> > reviewing. Would it be an option to pass it to you when it is ready?
> > The man
> > pages for xmlto says that it could widen its output capability with
> > passivetex...
>
> Yes.
>
>
> Thank you.
>
> --
> +-------------------------------------------+
> | Marcel Telka   e-mail:   marcel@telka.sk  |
> |                homepage: http://telka.sk/ |
> |                jabber:   marcel@jabber.sk |
> +-------------------------------------------+
>