Re: question about placements in /usr/share/xml
On Tue, 3 Feb 2004 06:35:12 -0500 Neil Roeth <neil@debian.org> wrote:
>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.
I too misunderstood .. Great.
>
> > > 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.
> >
Cooler still.
> > > It would make
> > > more sense if the docbook-xml package depended only on xml-core
> > > and the docbook package depended only on sgml-base.
> >
Yep that would make sense and be great.
> > 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.
So am I.. dockbook XML would need both.
>
> > > 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.
>
Mostly thanks :)
[1]So only XML compliant stuff goes in XML ?
I just spent all day convincing myself that that[1] would
a/ be a good thing (TM) and b/ that dockbook xml is not really valid XML
as it does not define it's DTD's as being in any particular namespace or
as valid xml documents).. however Functionally it certainly is and the
prologues for it's use declare a valid URI , which I guess is the same
as a name space...
It also occurred to me that a "rule set" for where the catalog files
might go like:
if /etc/sgml/catalog (is parsed) || prolog declared DTD\
is really under /usr/share/sgml;
then catalog (any format) lives under /usr/share/sgml
elseif /etc/xml/catalog (is parsed) || prolog declared DTD\
is really under /usr/share/xml;
then catalog.xml (XML Valid Only) lives under /usr/share/xml/
else
Application specific solution and not necessarily part of the XML
universe..
eval bugreport(101)
of course the xml sysref should be the full URI http:// file:// etc.
But that may be too strict.
fi
Thanks for posting this.
Pete
--
Todays fortune:
Today is the last day of your life so far.
< http://www.gnu.org/software/tetum/ >
< http://bigbutton.com.au/~gossner >
< gossner@arcom.com.au >
>--
>Neil Roeth
>
>
>--
>To UNSUBSCRIBE, email to debian-sgml-request@lists.debian.org
>with a subject of "unsubscribe". Trouble? Contact
>listmaster@lists.debian.org
Reply to: