Re: question about placements in /usr/share/xml
Ardo van Rangelrooij <ardo@debian.org> writes:
> Ok, let's start with the basics: The purpose of these symlinks is to support
> legacy. But what kind of legacy? Legacy from an SGML catalog system point of
> view or legacy for tools/applications that don't use the SGML catalog system
> but expect to be able to directly access XML entities under
> /usr/share/sgml?
I would imagine, in particular, we mean by legacy supporting XML tools
that didn't support entity resolution using XML catalogs, and were
therefore pointing at the file names directly. This seems to be the
clear meaning to me, since if they did support entity resolution
(either with SGML catalogs or XML catalogs) the fact that the
filesystem location changes doesn't make a difference.
[...]
> So, for legacy from an SGML catalog system point-of-view we don't need to
> symlink; we just need to update the package SGML catalogs to point to the
> new location under /usr/share/xml.
Right.
> This leaves legacy support for tools & applications that do their
> own thing. How many of those do we have and which are those? Can
> they be fixed?
I believe there are a number of XML processing tools that do not XML
standard entity resolution. I can think of one of the top of my head:
saxon. You can link in an entity resolver with saxon, however. As
far as I remember, tho, stock saxon doesn't use one.
But even more, regardless of the tool used, there must be a large
number of documents used by our users which have SYSTEM doctype
entries, like this:
<!DOCTYPE svg SYSTEM "/usr/share/sgml/dtd/svg10.dtd">
Can we fix this? No, only the user can. Can we support it? Yes,
there are two ways:
1) /usr/share/sgml/dtd/svg10.dtd is a (relative) symlink pointing to
the new location
2) delegateSystem entries in XML catalog -- no symlink req'd
These two are redundant, but I've been doing both, because case (2)
only covers XML tools which support catalog lookup.
I guess, if we really hated the symlink idea, we could pretty much
just banish package support for this case. That's an option too.
--
.....Adam Di Carlo....adam@debian.org.....<URL:http://www.debian.org/>
Reply to: