Re: question about placements in /usr/share/xml
Mark forgot to send his reply to the list, so I am quoting it in its
entirety here. It definitely sets my mind at ease. :-)
On Feb 2, Mark Johnson (mrj@debian.org) wrote:
> On Mon, Feb 02, 2004 at 06:49:04AM -0500, Neil Roeth wrote:
> > 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.
>
> This is indeed the case. No SGML resources (i.e. DTDs, ...) would get installed
> /usr/share/xml.
Good.
> > 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.
>
> Nope, I think you've got the situation reversed. XML resources would get installed
> under /usr/share/xml, as would their SGML catalogs, when appropriate. OTOH, DocBook
> SGML would not install a single file under /usr/share/xml. All of its stuff would
> go under /usr/share/sgml. There is no XML Catalog for DocBook SGML, so there's no
> reason to install any of its files under /usr/share/xml.
This was not clear to me from the prior messages, I thought for some reason
SGML catalogs for SGML resources were ending up under /usr/share/xml. Thanks
for the clarification.
> > 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.
>
> Not true. DocBook SGML would have no dependency on xml-core, as it cannot use the XML
> Catalog system.
>
> > 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 disagree. Some XML stuff can indeed use the SGML catalog system, and some XML stuff
> definitely can't (e.g. docbook-xsl). So, yes, docbook-xml would indeed depend on both
> xml-core and sgml-base, which IMO seems perfectly natural. OTOH, docbook-xsl would
> depend only on xml-core. There's really no inconsistency.
I'm convinced.
> > 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.
>
> The motivation for /usr/share/xml is that there is a growing number of xml and
> related resources that simply don't qualify as SGML. For example, as soon as you
> add an 'xml:base' attribute to an XML element, it's no longer SGML. SGML is more
> general in some ways, XML (and related specs) are more general in others. The
> important point being that XML will continue to grow in both resources and in the
> number of related specifications. This latter point is the primary reason for
> /usr/share/xml.
That what was I thought the motivation was, until I read (perhaps misread)
this thread.
> > > 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.
>
> Again, the SGML structure will have no references at all to /usr/share/xml.
>
> Hope this clarifies some things...
Absolutely, thanks.
--
Neil Roeth
Reply to: