FHS-2.3 -- /usr/share/xml

[Mark Johnson]

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
>>hierarchy....

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 
Workgroup [again:])

>>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
>          /usr/share/xml/$company/$product/$version
>       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:

/usr/share/xml/docbook/simple/
                               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:
http://debian-xml-sgml.alioth.debian.org/xml-policy/
There's also a  Debian SGML policy, but it badly needs to be updated:
http://debian-xml-sgml.alioth.debian.org/sgml-policy/

>     - 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:
>    http://xmlsoft.org/catalog.html
>    http://www.oasis-open.org/committees/entity/spec.html

This latter link is outdated. The current versionof the XML Catalogs 
spec is here:

http://www.oasis-open.org/committees/download.php/4952/wd-entity-xml-catalogs-1.0_2e.html

>    http://xmlsoft.org/guidelines.html

I would also like to add James Clark's excellent summary of SGML 
catalogs (aka TR9401:1997):

http://www.jclark.com/sp/catalog.htm

Or the original spec itself:

http://www.oasis-open.org/specs/tr9401.html

Oh yeah, and FWIW, in order for fedora to be LSB 2.0-compliant, it has 
to FHS 2.3 compliant, as well.


Cheers,
Mark


>  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.
> 
> Daniel
> 


-- 
----------------------------------------------------------
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