Re: question about placements in /usr/share/xml
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 :)
(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.
I would seem sensible to put the catalogs in the same tree as the DTD's
they refer to.
That is SGML catalogs under /usr/share/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.
- SGML catalogs need not follow the rules of namespace system ID etc
that XML catalogs must.
- 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 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
docbook?
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. 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.)
(I also suspect that most parsing / validating applations do not yet
understand xml.)
> > [...]
> > > 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.
>--
>Neil Roeth
>
>
>--
>To UNSUBSCRIBE, email to debian-sgml-request@lists.debian.org
>with a subject of "unsubscribe". Trouble? Contact
>listmaster@lists.debian.org
Pete
--
Mesage Composed: Mon Feb 2 13:54:08 UTC 2004
Calendar events:
Feb 03 The Day The Music Died; Buddy Holly, Richie Valens, and the Big
Bopper are killed in a plane crash outside Mason City, Iowa, 1959
Feb 04 Cybernet inaugurated, 1969
Feb 04 Patricia Hearst kidnapped by Symbionese Liberation Army, 1974
< http://www.gnu.org/software/tetum/ >
< http://bigbutton.com.au/~gossner >
< gossner@arcom.com.au >
Reply to: