Re: question about placements in /usr/share/xml
On Tue, Feb 03, 2004 at 12:24:20AM +1030, Peter Gossner wrote:
> Hi sgml list,
> Just adding my 0.2.2 cents worth..
> I am about to attempt a how to that involves describing the TEI set up
> for the Freedict project. I would like to get it right :)
Great. I'm waiting for the TEI Consortium to redo their license, after
which I'll package their stuff for Debian. (Their also working on a
canonical FPI.) These things should be finished by the end of February,
FWIW.
> (comments in-line)
>
> On Mon, 2 Feb 2004 06:49:04 -0500 Neil Roeth <neil@debian.org> 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.
> I would put the case the other way around (as XML is a subset of SGML)
> but form the end users perspective this will become increasingly less
> obvious.
Only 'XML Proper' is a subset of SGML. As soon as you add, say, XML Base,
that's no longer the case. And the XML family of non-SGML specs continues
to grow...
> I would seem sensible to put the catalogs in the same tree as the DTD's
> they refer to.
I agree.
An SGML catalog for an SGML DTD should be in the same tree as
the SGML DTD. Similarly, an SGML catalog for an XML DTD should
be in the same tree as the XML DTD. There's really no inconsistency.
And it's much more practical this way.
> That is SGML catalogs under /usr/share/sgml .
Yep, but only for SGML DTDs. (Again, SGML catalogs are _not_ SGML.)
>
> - If a user or app is calling up an SGML DTD she would most likely
> expect to find the corresponding "configs" along the same path.
Agreed. No contradiction here. _All_ stuff for an SGML DTD will surely
lie under /usr/share/sgml, in the same tree as the DTD.
> - SGML catalogs need not follow the rules of namespace system ID etc
> that XML catalogs must.
Yep, they're simpler in many ways, partially because the catalog parsing
tools don't support all the SGML catalog directives.
> - As SGML stylesheets are normally handled the old SGML way (aka
> dsssl, lisp) and use their own route to do this , I would argue that
> it's conceptually cleaner to keep them separate.
Where has anyone said that SGML resources are to be installed in
/usr/share/xml??
The issue is where to install the SGML catalogs for XML DTDs.
I'm arguing that the SGML catalogs for XML DTDs should lie in the same
tree as the XML DTD. That's it. Nothing more complicated than this.
> -Where DTD's are dual purpose (and why not:) it gets harder.
> In both cases I am aware of the underlying DTD is really SGML with
> "remapped" or overidden entities/attributes etc. TEI.2 P4 XML and
TEI is really different in this respect, and may require special
treatment.
> docbook?
DocBook is not the same as TEI in this regard. In the future, DocBook
SGML will even go away. I wouldn't put docbook in the same category as
TEI also because the SGML and XML versions are shipped as different upstream
packages, so the division is much clearer. This, however, is not the case for
TEI - which is why it may merit special consideration.
> The Application catalogs on both systems while using differing formats
> can route to the correct final catalog. Transparently as they are
> designed to do. Certainly the solution of everything under the XML
> branch will work.
As will the SGML branch, as no one is proposing any changes to the
how the SGML resources are handled.
> Especially at the package install level. However ..
>
> Consider:
> Schemas and DTD's do get edited ,extended, regrouped, modified etc and
> my understanding is that this _should_ go into the /usr/local/share/{xml
> sgml} in which case consider that you have only edited either one or the
> other of the branches (perhaps many) .. It is _easier to maintain_ if
> everything is together, _and_ mirrors the Debian install path.
>
> I would expect that a catalog file under XML to comply with the xml
> catalog DTD. That may not be the case with an sgml catalog (or some
> extra catalog I may need to add.)
But what if the SGML catalog also complies with the XML DTD?? Should
it not then go into the same tree?
>
> (I also suspect that most parsing / validating applations do not yet
> understand xml.)
XML ones do. So do the SGML ones, depending on the content of the XML
they're parsing. Case in point: one can use the docbook SGML toolchain to
process docbook XML files.
> > > [...]
> > > > 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.
>
> I would also expect this. (or at least symlinks)
>
> >
> >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.
>
> I would be more than surprised I would think I had made some mistake .
> Consider source install (/usr/local) and mods that may be made.
> Doesn't keeping them separate make it easier and cleaner to move stuff
> to legacy, and simplify dependencies ?
>
>
> >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.
This is mistaken: the SGML structure has and will not have a mix of
references to both /usr/share/sgml and /usr/share/xml.
True, some SGML catalogs will point to XML DTDs in /usr/share/xml, but
I think this is a different issue than the one you brought up.
Cheers,
Mark
--
-------------------------------------
Mark Johnson <mark@dulug.duke.edu>
Debian XML/SGML <mrj@debian.org>
Home Page: <http://dulug.duke.edu/~mark/>
GPG fp: DBEA FA3C C46A 70B5 F120 568B 89D5 4F61 C07D E242
Reply to: