Update to psgml

I wrote to Andreas awhile back about looking at updating the psgml package (for my own selfish purposes, of course). It took me awhile, but I've taken a stab at it at last. I would have posted a diff to xemacs-patches, but it's ... well, slightly enormous. So I stashed it in the only place I have available right now, which is <URL:http://www.ittc.ukans.edu/kan/psgml-11022000.tar.gz>;. There are no links to that file (since it doesn't really belong there!); you have to go directly to that URL. It is 634K. I do not plan to leave it there for more than a month. If a few hardy souls wouldn't mind taking a look at it and letting me know what I messed up, I'd appreciate it. This is my first foray into making a package. It didn't seem terribly complicated, but that might be because I overlooked something. The rest of this message consist of notes on what I did to make the new package. I updated the lisp files to match psgml-1.2.1. I did my best to do the merge without tossing out patches submitted to the XEmacs team. I even included a patch to psgml-edit.el that was submitted a couple of months ago. I should pick out the differences and forward them to the psgml maintainer, but that will have to wait for another day. In trying to preserve old patches, I may have made some mistakes. In particular, I was unsure of the following: 1) In psgml-edit.el: - The current XEmacs psgml package uses tempo to do string insertion. However, psgml-1.2.1 does not do so. I didn't know if the use of tempo was an XEmacs team change, or if the psgml maintainer simply stopped using it. I went on the latter assumption for now, since there is no mention of the matter in the ChangeLog. - One change marked "Wing change" was removed by me. As far as I can tell, it is wrong, perhaps given subsequent development to psgml. It dealt with the insertion of end tags. 2) psgml-lucid.el was psgml-xemacs.el in the last XEmacs release of this package. Who changed the name? The ChangeLog is silent on that score, but I went ahead and changed the name from psgml-lucid.el to psgml-xemacs.el anyway. Also, I removed psgml-other.el from the distribution, as it contains FSF Emacs-specific code. The XEmacs-specific code is in psgml-xemacs.el. That wasn't bad, actually. All the work (and most of the diffs) came in etc/psgml. Many of the DTDs had updates (usually minor), so I imported a new set from w3.org. In addition, I did the following: FILES RENAMED ------------- 1) html-3.2f.dtd -> html-3.2.dtd This is the final version of the HTML 3.2 specification, and is appropriately named html-3.2.dtd. With the draft html-3.2.dtd gone (see html-3.2.dtd in the "FILES REMOVED" section), that name change has been made. 2) ie3tables.dtd -> ie30tables.dtd This change brings the name into conformance with w3.org usage. FILES REMOVED ------------- 1) Wing.ISOlat1.sgml This is not used by any of the DTDs, and it is superfluous anyway. This problem is taken care of in individual DTDs and html-latin.sgml. 2) html-2.dtd This DTD does not appear on w3.org. I presume this means it was a draft DTD. There is no point in keeping such an old draft around. Furthermore, html-2.dtd does not appear in the previous CATALOG, so nobody was able to use it anyway! Hence the number of people impacted by the removal of this file is zero. See the notes on html-2.1e.dtd in the "FILES ADDED" section. 3) html-3.2.dtd This DTD was a draft version of the HTML 3.2 specification. There is no point in keeping it now that the final version is available. See html-3.2f.dtd in the "FILES RENAMED" section. 4) webtechs.catalog Our new catalog has all of the stuff from w3.org that is needed to describe the DTDs present, and includes all relevent entries from this, so this is superfluous. 5) sinfo.dtd This DTD does not describe itself, give sample public identifiers, or otherwise give the user any clue as to what it might be. Plus, it isn't in the previous catalog either. Hence, anybody informed enough to be using it has a custom catalog and so can presumably handle adding the DTD to her personal collection. Actually, it looks like a DTD for dealing with RFCs, right? If somebody can help me get it into the CATALOG, that might be useful. It would also be useful to know if this DTD has been updated recently. FILES ADDED ----------- 1) ISOlat1.ent The ISO Latin-1 entity specification for HTML 1) html-2.1e.dtd The HTML 2.1e specification. Unfortunately, psgml steadfastly refuses to compile this DTD. I haven't discovered why yet. 2) html-3-as.dtd The HTML 3 specification, as extended by asWedit 2.0 in HTML 3 mode. 3) html-sq.dtd The HTML 3 specification, as extended by HoTMetal PRO 2.0 4) HTML4.decl Declarations for the April 24, 1998 W3 Recommendation for the HTML 4 specification. The other HTML 4 files were here already, but this one was missing. 5) HTML4.01.decl, html-4.01frame.dtd, html-4.01l.dtd, html-4.01s.dtd The August 24, 1999 W3 Proposed Recommendation for the HTML 4.01 specification. 6) xhtml* The January 26, 2000 W3 Recommendation for the XHTML (XML-based) 1.0 specification. 7) d* and cals-tbl.dtd Docbook 3.1 and CALS Table Model, the only non-(X)HTML DTDs now that sinfo.dtd (whatever that was) is gone. IANAL, but it seems safe to include this, given that it ships with most Linux distributions (and the license appears to be quite unrestrictive). In addition, I added nearly all of the DTDs to ECAT and compiled them. The exceptions were html-2.1e.dtd, which causes an error in psgml's DTD compiler, and some of the supporting (i.e., included) DTDs, which are not meant to be used as standalones. They get compiled into whatever uses them, so there is no point in compiling them separately. For the future, what should be done with htmlpro.dtd and README.htmlpro? The URL given in README.htmlpro is dead. Further investigation shows that Silmaril has moved to a new web server. The pages on the new server are full of dead links, and none of them lead to or so much as mention htmlpro. Also, the ISO_8879-1986/entities directory needs to be cleaned up. What is the point in having 2 copies of each file, with differing names? We should be able to stick to 1 naming scheme and get rid of the other one. Does anybody know if XML DTDs need to be put into the catalog? To use them, you have to give both a system and a public identifier, right? So a catalog seems redundant, but I know basically nothing about XML, so I don't know what The Right Thing To Do is here. Finally, now that I have added a bunch of new DTDs, I'm starting to think that XEmacs should only ship with a handful of the most widely used ones. What's the point in having all those old versions of HTML around, for example? A few people might need them, but most won't. I suggest we keep HTML 3, 3.2, 4, and 4.01, XHTML 1.0, Docbook 3.1 (and maybe 3.0 as well), and ditch the rest, possibly with instructions on how to add them back in. Feedback is welcome. But then again, so are chocolate-covered peanuts. -- Jerry James Email: james(a)eecs.ukans.edu (formerly jerry(a)cs.ucsb.edu)