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. 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
