FHS-2.3 -- /usr/share/xml
mjohnson at redhat.com
Sat Jul 31 23:07:22 UTC 2004
Daniel Veillard wrote:
> On Sat, Jul 31, 2004 at 04:55:08PM -0400, Toshio wrote:
>>What is the future of FHS2.3 and fedora?
>>I was just looking for guidance on where to install some DTDs for a
>>package and found FHS-2.3 specifies a /usr/share/xml directory:
>> /usr/share/xml contains architecture-independent files used by XML
>>applications, such as ordinary catalogs (not the centralized ones, see
>>/etc/sgml), DTDs, entities, or style sheets.
Right, and /usr/share/sgml stores the same stuff for SGML. Most of
what's in FHS 2.3 regarding XML/SGML came out of some very spirited
discussions a couple years ago amongst developers from various
distributions who were trying to establish an XML/SGML component for
LSB. The names like "centralized" and "super" catalog are not at all
agreed upon amongst developers or distributions. No consensus was ever
reached, but the content somehow snuck itself into FHS 2.3.
>>FC2 uses /usr/share/sgml for some of this and other pieces are strewn in
>>individual program directories under /usr/share. Even under FHS-2.2,
>>these things are specified to live under the /usr/share/sgml
There is at present no clear standard as to where packages should
install their files, and so they're sometimes splattered into random
locations. (I'm working to fix this by trying to form an LSB-XML/SGML
>>If this is going to be our convention, I'll build to accomodate it,
>>otherwise I'll do what most packages seem to do right now: install in
>>their own directory under /usr/share/<PROGNAME>
> I think I suggested the /usr/share/xml split from /usr/share/sgml.
Yeah, and man IIRC were you flamed for it!
> This came out of serious troubles with catalogs, where SGML definitions
> for entities were clashing with the same definitions for XML tools.
> If you intend to put XML resources on the filesystem for global access
> I suggest the following steps:
> - use a subdirectory for /usr/share/xml for storing those resource
> please make it unique, a scheme like
> should be fine
Agree here, as well. For example, I'm packaging Simplified DocBook (XML)
V1.1 (which contains versions 1.0 & version 1.1) and will install the
files into the following directories:
1.0/[package files here]
1.1/[package files here]
as well as putting <delegate* directives that point to the package
catalogs, /etc/xml/<package>.xml, which then delegates the lookup to the
appropriate local catalogs. Note that the package catalogs are redundant
in the case of a package that only has one DTD.
This is very similar to the way Debian does it. Their system is spelled
out in great detail in their XML Policy Working Draft:
There's also a Debian SGML policy, but it badly needs to be updated:
> - register system and public ids using an XML catalog hooked
> to /etc/xml/catalog , best being by using delegates to a subcatalog.
I would add that XML DTD packages should also register themselves in the
SGML catalog system as well; a number of SGML tools can still make use
of XML resources. (An example: processing DocBook XML w/ the DocBook
DSSSL stylesheets and jade.)
> Check how the docbook-dtds RPM does to register/unregister those resources.
> Additional informations about catalogs and design can be found at:
This latter link is outdated. The current versionof the XML Catalogs
spec is here:
I would also like to add James Clark's excellent summary of SGML
catalogs (aka TR9401:1997):
Or the original spec itself:
Oh yeah, and FWIW, in order for fedora to be LSB 2.0-compliant, it has
to FHS 2.3 compliant, as well.
> The big question is whether you want those data to be reused outside
> your application. If no, they are just data, the fact that they happen
> to be XML doesn't matter, and /usr/share/<PROGNAME>-<VERSION> is just
> fine, but if you expect to export and share those data (which is really
> the #1 reason to use XML in the first place IMHO) then register relevant
> resources in the catalog. The resources I pointed out try to explain
> why this matters and how this should be achieved.
Mark Johnson <mjohnson at redhat.com>
Red Hat Documentation Group <http://www.redhat.com>
Tel: 919.754.4151 Fax: 919.754.3708
GPG fp: DBEA FA3C C46A 70B5 F120 568B 89D5 4F61 C07D E242
More information about the devel