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-cata...
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(a)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