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
