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