Re: question about placements in /usr/share/xml
On Feb 1, Adam Di Carlo (adam@onshored.com) wrote:
> Mark Johnson <mrj@ibiblio.org> writes:
>
> > On Sat, Jan 31, 2004 at 06:07:40PM -0600, Ardo van Rangelrooij wrote:
> >> So, the root SGML catalog file only knows about package
> >> SGML catalog files that live in /etc/sgml which on their turn only
> >> know about local SGML catalogs living under /usr/share/sgml.
> >
> > I, again, don't understand the need to put SGML catalogs under
> > /usr/share/sgml. There's nothing inconsistent about doing it this way.
> [...]
> > There's no way that I'll ever agree with what you're proposing. Someone
> > else needs to weigh in, so we can get some sort of consensus.
>
> I'm with Mark here. If I have XML data going in
> /usr/share/xml/docbook/4.0/ for instance, obviously I'll have my XML
> catalog, /usr/share/xml/docbook/4.0/catalog.xml. Doesn't it also make
> sense to have my SGML catalog, /usr/share/xml/docbook/4.0/catalog ?
>
> Seems to make sense to me, as a user or as a package maintainer.
Not to me, in either role. The FHS says:
"/usr/share/sgml contains architecture-independent files used by SGML
applications, such as ordinary catalogs (not the centralized ones, see
/etc/sgml), DTDs, entities, or style sheets."
I infer from this and the corresponding XML section that if /usr/share/sgml
and /usr/share/xml both exist, then I would find all the files used by SGML
applications in /usr/share/sgml and all the files used by XML applications in
/usr/share/xml. I would expect all file references in the SGML files to be
into the /usr/share/sgml hierarchy, or into a package specific subdirectory,
but not into the /usr/share/xml hierarchy.
If I installed nothing but SGML packages, I would be surprised if
/usr/share/xml even existed, and even more surprised if it contained the bulk
of the information for my SGML system, which sounds like the direction this is
heading. Also, in the proposed Debian XML/SGML policy (perhaps an obsolete
version) it says that the xml-core package will create the /usr/share/xml
infrastructure, so in your example, where the DocBook 4.0 SGML catalog is in
the /usr/share/xml hierarchy, the docbook package would have to depend on
xml-core as well as sgml-base, which seems totally nonsensical. It would make
more sense if the docbook-xml package depended only on xml-core and the
docbook package depended only on sgml-base.
I thought the problem was that our current setup has only /usr/share/sgml into
which all XML apps are shoehorned, and that the solution involved creating
/usr/share/xml so that everything would make sense from an XML perspective.
ISTM that the current solution is heading in the direction of doing that, at
the expense of making things nonsensical from an SGML perspective.
> Symlinks should only be provided to support *legacy* locations --
> e.g., the file used to be in /usr/share/sgml/docbook/4.0, but now it's
> /usr/share/sgml/docbook/4.0 .
>
> Lets not overcomplicate matters please. I don't see any reason why
> SGML catalogs cannot reside in /usr/share/xml/.... Remember the
> catalog is just the registration of some content (a DTD or entity
> file). That is to say, its metadata. Whether the *content* itself is
> SGML or XML should determine whether it goes in /usr/share/sgml or
> /usr/share/xml .
I think anyone who tried to understand the SGML structure that had some mix of
references to both /usr/share/sgml and /usr/share/xml instead of just to
/usr/share/sgml would think the former is overcomplicated relative to the
latter.
--
Neil Roeth
Reply to: