This is the mail archive of the cygwin-apps@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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/000289.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 |
+-------------------------------------------+


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]