Re: status of /ust/lib/sgml -> /usr/share/sgml transition
Ian Zimmerman <itz@speakeasy.org> writes:
> itz> The main problem with this interim solution comes when you use
> itz> your own DTDs that refer to ISO entities (as most do). You
> itz> cannot put them in /usr/{lib,share}/sgml because that's off
> itz> limits to user modification,
>
> Adam> I don't agree. According to the copyright, you can make minor
> Adam> changes that don't change the structure to accomodate local
> Adam> integration tasks. I got this right from the W3C and Norm Walsh
> Adam> both.
>
> Not what I meant. What I meant is that I (as a user) can't (or
> rather, won't) drop any of my files (private company or personal DTDs)
> there, because it's against The Debian Way (TM).
Right.
> I put them in /usr/local/share/sgml instead. But then, without
> public IDs,
I assume you're trying to support XML tools that are too retarded to
know about catalogs?
> I can't refer to the ISO stuff except by absolute
> path. (or by a CGI hack :)
Hmm. Relative pathing should work assuming SGML_SEARCH_PATH is working
right.
But the fact is that if you don't have catalog support, you have to do
nasty hacks such as system-specific paths. That why system IDs suck,
and public IDs suck less. In other words, if you don't have catalog
support, you pretty much have to throw any modicum of elegance and
maintainability out the window.
--
...Adam Di Carlo..<adam@onshore-devel.com>...<URL:http://www.onshored.com/>
Reply to: