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 ([EMAIL PROTECTED]) wrote: > On Mon, Feb 02, 2004 at 06:49:04AM -0500, Neil Roeth wrote: > > On Feb 1, Adam Di Carlo ([EMAIL PROTECTED]) wrote: > > > Mark Johnson <[EMAIL PROTECTED]> 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
