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.
>
> 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....
>
> 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 .
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
- register system and public ids using an XML catalog hooked
to /etc/xml/catalog , best being by using delegates to a subcatalog.
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
http://xmlsoft.org/guidelines.html
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
--
Daniel Veillard | Red Hat Desktop team http://redhat.com/
veillard@xxxxxxxxxx | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
