Michael Laing <[EMAIL PROTECTED]> writes: > I'd suggest that we try to use pub id's wherever possible - which means > that tools will have to be able to find the catalog -
Yes -- there is no tool in Debian yet that doesn't understand socats. > and I suggest we use relative file URI's for sys id's. Interesting -- relative to SGML_SEARCH_PATH you mean. > For example, on my potato system, nsgmls has compiled in (apparently) > that it should look in '.', '/usr/local/share/sgml/', > '/usr/local/lib/sgml/', and '/usr/lib/sgml/'. Slink is a little > different. I'm not aware that nsgmls SGML_SEARCH_PATH changed from slink to potato. > Thus the following works: > > Given an XML document mydoc.xml that starts with: > > <?xml version="1.0" encoding="ISO-8859-1"?> > <!DOCTYPE sources SYSTEM "ucinput.dtd"> > ... Hmm.... I use stuff like: <?xml version="1.0"?> <!DOCTYPE project PUBLIC "-//onShore//DTD Projex Project Tracking//EN" "dtd/projex.dtd"> This works fine -- note that nsgmls/jade at least will consult the PUBID iff the SYSID doesn't exist. > I can't seem to actually get nsgmls or psgml to use the catalog tho... I > haven't checked other tools... Really? Look at SGML_CATALOG_FILES env var too. Should work... it's been tested.... > IF the tools follow the 'allowed' logic in the spec, one should be able > to put in a bogus filename and have the catalog lookup take precedence > if the catalog and an entry in it are found. Yup -- that is one of the things I do sometimes, too. -- .....Adam Di [EMAIL PROTECTED]<URL:http://www.onShore.com/>
