Re: status of /ust/lib/sgml -> /usr/share/sgml transition
Mark> 1. Entity References in Upstream Files (mods, dtds, ...)
Mark> In the case of the jrefentry.dtd [3], the upstream source
Mark> defines the full docbook xml dtd as the entity '%docbook' and
Mark> then references it as follows:
Mark> <!ENTITY % docbook PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
Mark> "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd";>
Mark> %docbook;
Mark> To be on the safe side, when I packaged this dtd I changed the
Mark> SYSTEM ID to a relative path and ditched the PUBLIC ID like so:
Mark> <!ENTITY % docbook SYSTEM "../../../dtd/xml/4.1.2/docbookx.dtd">
Mark> %docbook;
itz> I think this is terrible. It means going along with the fact that XML
itz> tools without catalog support are broken. Why should users of tools
itz> that get it right (Jade) continue to suffer for that?
Mark> Well, I did that when we first started packaging the xml stuff. And it
Mark> should work just fine whether or not you have catalog support.
Of course I understand the reasons why it might be done, and by "this
is terrible" I didn't at all mean to disparage you.
The main problem with this interim solution comes when you use your
own DTDs that refer to ISO entities (as most do). You cannot put them
in /usr/{lib,share}/sgml because that's off limits to user
modification, so you can't refer to the entities with relative paths,
so you must choose between SYSTEM IDs with absolute paths (ouch!) or
maintaining your own parallel catalog file.
--
Ian Zimmerman, Oakland, California, U.S.A.
The easiest way to win an argument: ridicule your opponent's basic
assumptions by stating their negation and postfixing it with ", right?"
GPG pub key: 433BA087 9C0F 194F 203A 63F7 B1B8 6E5A 8CA3 27DB 433B A087
Reply to: