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

Peter Ring
Wed May 21 07:11:00 GMT 2003

Executive summary: doing the Right Thing wrt. XML resources
implies a growing number of packages. A scheme for bundling
XML resources in 'virtual' packages could be useful.
A scheme for maintenance of XML catalogs is crucial.


Yep, from a resource-centered view, it is a good thing not to
bundle XML resources that are only incidentally related (e.g.
because someone happened to need them simultaneously at a
particular point in time for a particular application).

You don't want to re-release resource A-1.2 just because there's a
new resource B-7.4 (and A-1.2 was incidentally bundled with B-7.3).
Also, you still might need resource B-7.3 even though B-7.4 is
'better'. It's quite often the case with processing stylesheets
that a newer version doesn't quite work for specific documents or
specific version of other tools.

DocBook DTDs are traditionally bundled with two table models and
the ISO 8879:1986 character entity sets that are also useful
resources in their own right. It has never bitten me and it is not
worth the trouble to unbundle this particular upstreams bundling.
These resources are very stable, and it is easy to make them also
accessible outside any specific version of the DocBook bundle.
But it is not, IMHO, the best pattern.

Anyway, the resource-centered view does imply that

- there will potentially be a number of packages

- subsequent releases of new versions do not render old
  versions obsolete

- entity resolution (catalogs) must be managed by install
  and uninstall scripts

To ease installation, it might be a good idea to have 'virtual'
packages that essentially just require recommended versions
of other packages.

I'm trying to design a scheme for entity resolution (catalogs)
that minimizes the number of times any catalog must be updated.

The canonical URL for a XML resource will usually be composed
of a namespace owner part (based on a domain name), a resource
name part, and a version identification part, followed by
file names related to the resource.

The resource name part might be something like 'docbook/xml',
while the version identification might be something like a
'major.minor.patch' or 'release.revision' number. It might
be convenient to put a catalog just above the versions of
that resource:

  catalog -- delegatePublic for each resource
             rewrite of system and URI as fallback

      catalog.xml -- rewrite or delegate
        catalog.xml -- included in docbook/xml/4.0 package

Or the resource name and revision may be mixed up into
something like 'prefix/yyyy/mm/dd'. This pattern is typically
used for namespace names that are also resolvable as URLs.
In this case, different major releases of a resource are
located unrelated places below the 'prefix' level, but
entity resolution of public identifiers is typically not
necessary (these resources don't have public identifiers):

  catalog -- rewrites system and URI


kind regards
     <@ @>         Peter Ring
|         Address  Ceresvej 16, st.
|                  DK-1863 Frederiksberg C
|         Phone    +45 3331 4216
|         EMail

-----Original Message-----
[]On Behalf Of Andreas
Sent: 20. maj 2003 01:43
Cc: Peter Ring
Subject: RE: docbook-xml42, docbook-xsl, xmlto (RE: Pending package
status (09 May 2003))

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.

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

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


<snip />

More information about the Cygwin-apps mailing list