Newsgroups: comp.text.sgml Date: 03 Mar 1992 12:32:10 UT From: Mike Popham \ Organization: Computer Unit, Exeter University Message-ID: <2111@exua.exeter.ac.uk> Subject: SGML application for terminological entries As a member of a relevent BSI (British Standrds Institute) committee, I have received copies of a new work item proposal started by ISO/TC 37/SC 3. The Title is "Computational Aids in Terminology - Formats for Data Interchange - SGML application for terminological entries". The Scope states "The standard (will) provide a universally applicable format for terminological data based on SGML designed primarily for interchange purposes". I have about 12 sides of relevent supporting documents and letters which I can fax to anyone who responds with an interest. I have been informed that the UK will abstain on the New Work Item ballot unless someone can give a good reason why the UK should get actively involved. If there is anyone out there who thinks the UK (and the UK-end of the TEI) should get actively involved, then let me know -- smartish, please. [Note from Michael Popham: TEI/AI7 - Analysis and Interpretation Working Group, are already in liaison with ISO/TC 37/SC 3] Anyone outside the UK who wishes to become involved should contact their own national standards organization, although I can still fax details if required. [Note: The UK is only an Observer-member of TC 37.] Paul Ellison. Director - The SGML Project Newsgroups: comp.text.sgml Followup-To: comp.text.sgml Date: 03 Mar 1992 19:31:11 UT From: Jeff Lankford \ Reply-To: jlankford@nrtc.northrop.com Organization: Northrop Research and Technology Center Message-ID: <35793@gremlin.nrtc.northrop.com> Keywords: CONCUR Subject: Seeking Pratical Experience w/ CONCUR ----------------------------------------------------- I recently devised a use for the CONCUR feature. (CONCUR is the means by which multiple, concurrent schemas of a document are supported.) Before I go charging off, I would appreciate practical advice from the readership. Please direct all replies to me, and I will summarize for the group. The kind of information I'm interested in includes: 1) What is your application, i.e., for what purpose do you use CONCUR? 2) What SGML processor do you use? Do you reject use of any SGML processor for its lack of CONCUR support? 3) Any subtle conflicts that arose from your use of CONCUR? Perhaps with other features, such as PI? P.S. So you don't die of curiousity, the application I have in mind would use CONCUR to track views of a document (component) at different stages in processing, e.g., persistant storage handle view, retrieved content view, layout style view, and so on. jpl Newsgroups: comp.text.sgml Date: 04 Mar 1992 06:51:57 UT From: Andre Lehovich \ Organization: Brown University Department of Computer Science Message-ID: <1992Mar4.065157.22177@cs.brown.edu> Subject: sgml editors I checked the FAQ and several ftp sites, but couldn't find anything that fits the bill. Are there any free SGML editors out there? What about emacs/epoch modes? Thanks, --AndreL Andre_Lehovich@brown.edu AndreL@brownvm.bitnet al@brunix.uucp Newsgroups: comp.text.sgml Date: 06 Mar 1992 22:01:33 UT From: ""Dr. "Eliot Kimber" Macro"" \ Message-ID: <9203062208.AA28014@ucbvax.Berkeley.EDU> Subject: DTD for Standard Bibliographic References I need to define a set of bibliographic description elements. I am not a library scientist and have little experience with this area. Does there exist a standard or proposed standard set of bibliographic elements that are compatible with whatever electronic library systems exist? Does anyone have hints where I can go to learn more? In a future where everything is on line, it seems especially important that there be a defined standard for bibliographic references. Thanks, Eliot Kimber Internet: drmacro@ralvm13.vnet.ibm.com Dept E14/B500 IBMMAIL: USIB2DK9@IBMMAIL Network Programs Information Development Phone: 1-919-543-7091 IBM Corporation Research Triangle Park, NC 27709 Newsgroups: comp.text.sgml Date: 09 Mar 1992 05:25:59 UT From: Bill Simpson-Young \ Organization: ACUS Australian Centre for Unisys Software, Sydney Message-ID: <1992Mar9.052559.11273@syacus.acus.oz.au> Subject: SGML Font descriptions Hi, I need to get hold of some font descriptions (font attribute sets and metrics) in the SGML format described in ISO 9541 (Font Information Interchange). Any font is fine, but the "ISO Fonts" (defined in ISO 10180 - SPDL) would be great. Also, if anyone knows of or has a conversion utility for converting from Adobe font metric files to SGML font files, I'd like to get hold of this. Thanks in advance, Bill ----------------------------------------------------------------- Bill Simpson-Young, Australian Centre for UNISYS Software (ACUS) 115 Wicks Rd, North Ryde, NSW, 2113, Australia Internet: bill@syacus.acus.oz.au Tel: +61 2 390 1344 Fax: +61 2 390 1391 Newsgroups: comp.text.sgml Date: 09 Mar 1992 15:32:01 UT From: Iftikhar Zaman \ Organization: Oxford University Computing Service, 13 Banbury Rd, Oxford, U Message-ID: <3081@inca.comlab.ox.ac.uk> Subject: SGML for Arabic? Anyone know of any SGML parsers, validators or editors for Arabic? I would appreciate it if you would mail any responses back directly to me as I don't get much time to read news...I will post a summary if there is anything to summarize. Thanks. Iftikhar Zaman Newsgroups: comp.text.sgml Date: 10 Mar 1992 17:47:35 UT From: lou@vax.oxford.ac.uk Organization: Oxford University VAXcluster Message-ID: <1992Mar10.174735.4897@vax.oxford.ac.uk> Subject: ARCSGML for VMS?? Does anyone know of a port of the ARCSGML parser to the VAX VMS environment? I can't believe no-one's already done it, but my nearest ARCHIE doesn't seem to know of one. Can it be that I actually have to roll up my sleeves and do it myself? Tsk tsk. Lou Burnard TEI EuroEd Newsgroups: comp.text.sgml Date: 12 Mar 1992 04:29:32 UT From: "C. M. Sperberg-McQueen" \ Organization: University of Illinois at Chicago Message-ID: <92071.222932U35395@uicvm.uic.edu> References: <9203062208.AA28014@ucbvax.Berkeley.EDU> Subject: Re: DTD for Standard Bibliographic References Three pointers for Eliot Kimber on elements for bibliographic references: (1) the various national and international standards, e.g. ISO 690 and the now-withdrawn ANSI Z39.29, (2) the International Standard Bibliographic Description (a whole series with specific adaptations of a general model to specific types of object), and (3) the relevant sections of the TEI Guidelines, which are a fairly radical but perhaps still useful simplification of the ISBD analysis. Of course, version 2 of the Guidelines will be even better, when it comes out, which will be sooner, the sooner I end this posting and get back to work. -C. M. Sperberg-McQueen ACH / ACL / ALLC Text Encoding Initiative University of Illinois at Chicago Newsgroups: comp.text.sgml Date: 12 Mar 1992 15:58:28 UT From: Marilyn Kotwal \ Organization: Hewlett-Packard Company, Apollo Division - Chelmsford, MA Message-ID: <1992Mar12.155828.16971@apollo.hp.com> Keywords: sgml, framemaker, interleaf Subject: Do FrameMaker or Interleaf convert to SGML? Is there any way to convert Interleaf versions 4 or 5 or FrameMaker 3.0 documents to an SGML format? -Marilyn Kotwal Newsgroups: comp.text.sgml Date: 16 Mar 1992 07:13:17 UT From: Bernd Nordhausen \ Reply-To: bernd@iss.nus.sg (Bernd Nordhausen) Organization: Institute of Systems Science, NUS, Singapore Message-ID: <1992Mar16.071317.29441@nuscc.nus.sg> Subject: Question: SGML '92 conference Is there going to be a SGML '92 conference like last years SGML '91? If so, does anybody know where and when it will be held? Cheers, Bernd -- Bernd Nordhausen (bernd@iss.nus.sg) Institute of Systems Science Ph: +65 772-6240 National University of Singapore FAX: +65 778-2571 Singapore 0511 Newsgroups: comp.text.sgml,comp.emacs Date: 16 Mar 1992 15:23:12 UT From: David Megginson \ Organization: University of Toronto - EPAS Message-ID: <1992Mar16.152312.20696@epas.toronto.edu> Subject: sgml-mode for emacs? Does anyone have an SGML mode for Gnu emacs yet? David ################################################################# David Megginson meggin@epas.utoronto.ca Centre for Medieval Studies david@doe.utoronto.ca University of Toronto 39 Queen's Park Cr. E. Newsgroups: comp.text.sgml,comp.emacs Date: 16 Mar 1992 16:08:45 UT From: David Megginson \ Organization: University of Toronto - EPAS Message-ID: \ References: <1992Mar16.152312.20696@epas.toronto.edu> <23055B@erik.naggum.no> Subject: Re: sgml-mode for emacs? In article <23055B@erik.naggum.no> erik@naggum.no (Erik Naggum) writes: David Megginson \ writes: | | Does anyone have an SGML mode for Gnu emacs yet? It would be nice to have, indeed. It was one of the first things that I wanted to do when I first learned about SGML, and it's probably going to be one of the last things I finish. OK, maybe that's a little too pessimistic, but I have found that unless you have a parser able to understand a DTD, you're into relatively deep trouble. There are two approaches which we could take here. The first would be simply to write a mode to make typing in SGML a little easier: revise the syntax table, etc. etc. The second is to make emacs into an SGML editor. I have to admit that this was also one of my dreams when I started using emacs a few weeks ago, since SGML is so easy to represent in LISP. Minimization is the biggest problem. If everything is in canonical form, all is dandy. However, keyboarding canonical form is a waste of user time, as well as being error-prone. It's also quite hard to read when the DTD is designed to help keyboarding using minimization. Precisely the problem. If every starting tag had an end tag, writing the mode would be a snap (M-x sgml-mark-tagged-region, etc. etc.). I don't even want to _think_ about SHORTREF! Also, parsing SGML backwards is kind of hard. Why backwards? Oh, because you don't want to parse from the beginning of a document every time you want to do something. Another solution is to use Emacs' markers, and put them at places where you know the parsing state. The amount of administrative information to keep track of is growing, and so are error modes and opportunities for internal confusion. ...and RAM use. I run emacs 18.57 on an Atari ST, under Minix. It does everything that emacs is supposed to do, but It already uses up about a third of all my free memory, and, of course, my system does not have swapping. In any case, we have to remember all the demacs users under MeSsyDOS. Not that I would give up, that wouldn't be me, but I'm now working on a parser in e-lisp. It works great: it returns, at this point, t or nil, according as the document is a valid SGML document or not. Very useful. I'm sure that I'm not alone in asking you to do this, but if you wouldn't mind posting what you have, it would be very interesting to see. Maybe I can get this thing done if it wouldn't be for my own needs, which are admittedly quite elaborate, but for somebody else's as an intermediate stage. What would you like to see a mode doing, Dave? Help you write? Help you validate it afterwards? Help you design DTD's? Expand to canonical form? Give you a list of open elements, and a list of which you can open at point? Yes, I would be happy to help. We can arrange this by private mail. Are there enough people out there using GNU Emacs and SGML that this would be a useful thing to have? We already have *roff, tex, latex modes, and these are quite ugly, although useful. Do you guys have enough CPU power to run GNUS, or should we aim for a smaller CPU hog? I think that my Atari ST would go on strike if I tried to run Gnus ;-) With the free sgmls parser available, I think that a lot of people are starting to look at SGML more seriously. I am just finishing a doctorate on Old English spelling, written in SGML and printed using LaTeX -- an excellent test for any sgml-mode. Suggestions are welcome. A discussion of interactive aspects of entering and modifying SGML documents is pertinent, too. (I can't stand WYSIWYG, so a lot of important developments relevant to this topic may have passed me by. I'm sure there are important issues raised in WYSIWYG-type editors which (could) have impact on a text editor. Anyone?) In theory, you could hold the entire document internally in a giant list, with the format \ \ \: '(poem nil (title nil "A Short Poem") (stanza ((n 1)(type normal)) (line ((n 1)) "Roses are red") (line ((n 1)) "Violets are blue"))); however, this would use an awful lot of memory (you could use markers instead of strings for the PCDATA), and you would constantly have to keep the memory structure and the buffer contents synchronised. Perhaps sgml-mode should know about and use sgmls, just like dired knows about and uses ls(1). David -- ################################################################# David Megginson meggin@epas.utoronto.ca Centre for Medieval Studies david@doe.utoronto.ca University of Toronto 39 Queen's Park Cr. E. ################################################################# Newsgroups: comp.text.sgml,comp.emacs Date: 16 Mar 1992 17:16:29 UT From: Erik Naggum \ Reply-To: Erik Naggum \ Organization: Naggum Software, Oslo, Norway Message-ID: <23055B@erik.naggum.no> References: <1992Mar16.152312.20696@epas.toronto.edu> Subject: Re: sgml-mode for emacs? David Megginson \ writes: | | Does anyone have an SGML mode for Gnu emacs yet? It would be nice to have, indeed. It was one of the first things that I wanted to do when I first learned about SGML, and it's probably going to be one of the last things I finish. OK, maybe that's a little too pessimistic, but I have found that unless you have a parser able to understand a DTD, you're into relatively deep trouble. Minimization is the biggest problem. If everything is in canonical form, all is dandy. However, keyboarding canonical form is a waste of user time, as well as being error-prone. It's also quite hard to read when the DTD is designed to help keyboarding using minimization. Also, parsing SGML backwards is kind of hard. Why backwards? Oh, because you don't want to parse from the beginning of a document every time you want to do something. Another solution is to use Emacs' markers, and put them at places where you know the parsing state. The amount of administrative information to keep track of is growing, and so are error modes and opportunities for internal confusion. Not that I would give up, that wouldn't be me, but I'm now working on a parser in e-lisp. It works great: it returns, at this point, t or nil, according as the document is a valid SGML document or not. Very useful. Maybe I can get this thing done if it wouldn't be for my own needs, which are admittedly quite elaborate, but for somebody else's as an intermediate stage. What would you like to see a mode doing, Dave? Help you write? Help you validate it afterwards? Help you design DTD's? Expand to canonical form? Give you a list of open elements, and a list of which you can open at point? Are there enough people out there using GNU Emacs and SGML that this would be a useful thing to have? We already have *roff, tex, latex modes, and these are quite ugly, although useful. Do you guys have enough CPU power to run GNUS, or should we aim for a smaller CPU hog? Suggestions are welcome. A discussion of interactive aspects of entering and modifying SGML documents is pertinent, too. (I can't stand WYSIWYG, so a lot of important developments relevant to this topic may have passed me by. I'm sure there are important issues raised in WYSIWYG-type editors which (could) have impact on a text editor. Anyone?) Best regards, \ -- Erik Naggum | +47-295-0313 | ISO 8879 SGML | Memento, Naggum Software | | DIS 10744 HyTime | terrigena. Boks 1570, Vika | \ | JTC 1/SC 18/WG 8 | Memento, 0118 OSLO, NORWAY | \ | SGML UG SIGhyper | vita brevis. Newsgroups: alt.hypertext,comp.text.sgml Date: 16 Mar 1992 22:22:16 UT From: Erik Naggum \ Organization: Naggum Software, Oslo, Norway Message-ID: \ References: <1992Mar16.145017.170@aio.jsc.nasa.gov> Subject: Re: SGML [ for comp.text.sgml readers: this started as a request for information on hypertext standards, which Sean Levy replied to, with pointers to SGML and Hytime. Sean and I both recommended the Handbook. I haven't set the Followup-To header, but SGML issues should probably go to comp.text.sgml, only. ] Debra Bettis 283-4333 \ writes: | | Rather than endure the Bible on SGML (The SGML Handbook) by | Charles Goldfarb I recommend a new book. | | Practical SGML by Eric van Herwijnen | Kluwer Academic Publishers 1991 | | This is an excellent book for people who want to know more about | SGML but who may not be using SGML. It is easy to understand and | up to date. Hmmm. There is definitely a need for an introductory work on SGML, something which "mere mortals" can read and benefit from, and I'm afraid that all too many will find the word "endure" entirely appropriate for the Handbook, especially if they attempt to read all of it in one sitting. However, that said, I think the tutorial annexes to the standard (included in the Handbook), and the overview in the Handbook, go a long way to help people understand what's going on. From there to realizing the benefits and hazards of "going SGML" is of course a long way, and the Handbook is not intended to address this issue. It is therefore with significant discomfort that I do not commend any other book on SGML on the market today, including the above mentioned book. The reason is that Practical SGML is not so much about practical use of SGML as about all the problems the author encountered when he began to use SGML with some different tools. In my view, the author focuses too much on the tools, and too little on SGML, to the point where the two can be confused. To quote the summary section of Deborah A. Lapeyre's review of the book in the newsletter \, issue 16, October 1990: This book is not a perfect book. This is not the general SGML introduction that explains everything that all SGML users are still looking for. This book is a very personal volume, sort of "Travels Through the Land of SGML Software and What I Found There". You will want to read it for the same reason that you read any other travel volume: to acquire vicarious experience before trying out the real thing; to act as a guide to unfamiliar and uncharted territory; to compare another traveler's impressions with your own. This book packs a lot of SGML application experience into one volume. Her review is more positive than I am, and it's well worth reading before you go for the book. The review was re-published (by me) in comp.text.sgml 12 Apr 1991, and I will send out a copy to anybody who asks for it, or re-post if enough people ask. (It's also available in the SGML and comp.text.sgml archives at ftp.ifi.uio.no in the file /pub/SGML/comp.text.sgml/by.date/1991-04-12_04:56:10, for those of you who can use anonymous FTP.) I experimented with an SGML application for articles at the time, and this file is an example SGML document. It might or might not be a good example, but at least it's an example of SGML in real life. To conclude, I regret that there are no good introductory books on SGML at present, and would hope that if we let a thousand flowers bloom, we will be able to sort out the weeds in the process. So far, only three flowers have bloomed (the third is Martin Bryan's "An Author's Guide to SGML", which it's not), and the Handbook is for those who wish to learn the language, as opposed to learn about the language. I think we will have to wait for books on SGML which do not include a chapter or more on how the book itself was produced with SGML (i.e., the "look at what I can do with this new tool!" syndrome with books about new technologies), before we find the desired good beginners book on SGML. In the meantime, attending conferences and reading newsletters probably provides the best introductory material. I highly recommend \ The SGML Newsletter. Here's the entry from Robin Cover's excellent bibliography on SGML (see also ftp.ifi.uio.no: /pub/SGML/bibliography, or ask me to mail it to you): <96> \: The SGML Newsletter. This dedicated SGML publication is one of several forms of support given to SGML by the Graphic Communications Association (GCA). \ is GCA's premier publication organ covering SGML, published jointly by the GCA and SGML Associates, Inc. as "The Technical Journal of the SGML Community." It covers CALS SGML, SGML events and conferences, implementation case studies, SGML tutorials, product news, interviews and other topics. Current editors (1991) are Sharon C. Adler, Marion Elledge, Charles Goldfarb, Yuri Rubinsky and Ludo Van Vooren. Current subscription prices (December 1990) are annual 75 dollars US for GCA members, 150 dollars for non- members in the US and Canada, 200 dollars for foreign subscribers, and 125 dollars for foreign GCA Members. Other special offers are available with orders for back issues. Six issues per year. ... Address: Graphic Communications Association; Attention: Marion Elledge (Director, Information Technologies); 100 Daingerfield Road; Alexandria, VA 22314 USA; TEL: (703) 519-8160; FAX (703) 548-2867; TELEX: 510-600-0889. (I'm not sure about the accuracy of this information at this point, but when I find out more, I'll amend this posting. Help appreciated.) Best regards, \ -- Erik Naggum | +47-295-0313 | ISO 8879 SGML | Memento, Naggum Software | | DIS 10744 HyTime | terrigena. Boks 1570, Vika | \ | JTC 1/SC 18/WG 8 | Memento, 0118 OSLO, NORWAY | \ | SGML UG SIGhyper | vita brevis. Newsgroups: comp.emacs,comp.text.sgml Date: 17 Mar 1992 14:45:16 UT From: Sean.Levy@cs.cmu.edu Organization: Carnegie Mellon, Pittsburgh, PA Message-ID: \ References: <1992Mar16.152312.20696@epas.toronto.edu> <23055B@erik.naggum.no> \ Subject: Re: sgml-mode for emacs? Maybe I'm being a bit dense here, and I am new to SGML, but it seems to me that, given a particular DTD, one could pretty much automatically construct (elisp) code to customize an editor to work on instances of that DTD. You could handle SHORTREF (and other problems you raised) with alternate keymaps that get used as you move around (I don't recall how efficient this would be in the current implementation of GNU Emacs, but I could do this with a Tk-based editor with very little problem). So, there would be two parts to this hypothetical editing system (GNU Emacs mode, Tk widgets, BOS objects (an OOPL I have prototyped in Tcl), whatever): a DTD-independent, generic library of routines that the DTD-specific "modes" (or whatever you want to call them) use. Does this make sense to anyone else? Cheers, -- Sean ------------------------------------------------------------------------------ Sean Levy | n-dim Group / Engineering Design Research Center snl+@cs.cmu.edu | Carnegie Mellon University +1 412 268 5226 | 5000 Forbes Ave / Pittsburgh, PA / 15221 ------------------------------------------------------------------------------ Newsgroups: comp.text.sgml Date: 17 Mar 1992 19:51:58 UT From: Martin Beaudoin \ Organization: Le laboratoire de robotique de l'Institut de recherche d'Hydro-Quebec Message-ID: \ Subject: Info about SGML I would like to receive basic information about SGML. - What is it (I guess that it must be related to text editing)? - How does it compare with LaTex or TeX?? - Where can I get more information? Thank you! -- __ Martin Beaudoin mbeaudoin@ireq-robot.hydro.qc.ca Institut de recherche d'Hydro-Quebec mbeaudoin@ireq-robot.uucp Varennes, QC, Canada J3X 1S1 +1 514 652-8136 Newsgroups: comp.text.sgml Date: 17 Mar 1992 21:28:05 UT From: Ludo Van Vooren \ Message-ID: <199203172128.AA00779@support.avalanche.com> Subject: GCA SGML Events Schedule Somebody recently asked for the dates of the SGML'92 conference. I thought that it would be interesting to post the schedule of all the SGML-related events sponsored by Graphic Communication Association (GCA). If you want more info about any of these conferences or seminars contact GCA at: Graphic Communication Association 100 Daingerfield Road, Alexandria, VA 22314-2804 USA Tel: 703-519-8160 Fax: 703-548-2867 Here is the schedule: Mar 30-4/3 SGML Tutorial (Ottawa,ON) Apr 7 Preparing for an SGML System: The Conference (Washington,DC) 13-14 Digital Data Management: The Pharmaceutical Industry (Philadelphia,PA) May 11-13 International Markup '92 (Amsterdam, The Netherlands) 13-15 Documentation Europe Conference & Exhibition (Amsterdam, The Netherlands) Jun 4-5 SGML Management Tutorial (San Franscisco,CA) 15-19 SGML Tutorial Series (Dallas,TX) Jul 20 SGML Management Tutorial (Cambridge,MA) 21 How to Install an SGML System (Cambridge,MA) 22-23 Hytime Implementation Tutorial (Cambridge,MA) 24 SGML Conversion Tutorial (Cambridge,MA) Aug 24-28 TechDoc '92 Conference & Exhibition (San Francisco,CA) Sep 21-25 SGML Tutorial Series (Raleigh-Durham,NC) Oct 25-30 SGML '92 (Danvers,MA) 1993 Feb 21-25 TechDoc Winter '93 (San Antonio, TX) August 29-9/3 TechDoc '93 Conference & Exhibition (Anaheim,CA) =============================================================================== Ludo Van Vooren ludo@avalanche.com Director of Applications "The Ludster's mailbox" AVALANCHE Development Co. 947 Walnut Street (303)449-5032 Boulder, CO 80302 Fax: 449-3246 =============================================================================== Newsgroups: comp.text.sgml Date: 18 Mar 1992 00:08:35 UT From: Paul Hardiman \ Organization: Boeing Computer Services, Seattle Message-ID: <2056@bcstec.boeing.com> Keywords: SGML Subject: Grif feedback Interested in knowing of user responses to the Grif SGML editor from France. All that I have seen so far is literature. -- Ciao 4 Now --- Paul Hardiman (206) 728-8843 hardiman@bcstec.boeing.com Newsgroups: comp.emacs,comp.text.sgml Date: 18 Mar 1992 21:24:35 UT From: Erik Naggum \ Reply-To: Erik Naggum \ Organization: Naggum Software, Oslo, Norway Message-ID: <23057C@erik.naggum.no> References: <1992Mar16.152312.20696@epas.toronto.edu> <23055B@erik.naggum.no> \ \ Subject: Re: sgml-mode for emacs? Sean.Levy@cs.cmu.edu writes: | | Maybe I'm being a bit dense here, and I am new to SGML, but it seems to | me that, given a particular DTD, one could pretty much automatically | construct (elisp) code to customize an editor to work on instances of | that DTD. One could do this. However, a proper abstraction of that which "pretty much automatically" constructed the elisp code, is a data-driven approach from the DTD directly, and this would be much easier to do than the "DTD compiler". Besides, you don't always have a DTD -- the author may be typing it in to start his document from scratch. Then you would need to know the difference between editing the prolog and editing the document instance. Once you've built the necessary intelligence to recognize which of these states you're in, there's very little distance from there to recognizing more states, and thus is the data-driven editor born. Unlike some available parsers and applications, I'm very strongly opposed to the idea of making DTD-specific tools. SGML allows us to do application-independent validation, and the language itself lends itself very easily to generalized tools (pardon the pun). I also think one of the more beautiful features of SGML is that the documents themselves identify of which type they are instances. (In fact, documents also identify which syntax and character set they use, moving further towards the goal of self-identifying documents.) By separating the class information from the instance, which basically means that the user has to keep track of them instead of the computer, we take a step backwards, considering that we have this tool. A full SGML system should be able to know about application-specific software and dispatch to them according to the document type of the document. For instance, given a \ there should be an application known to the parser which would handle documents of types based on "foo". By "known to the parser" I do not intend to exclude the user, but see the need to interact with him to figure out how the document should be processed. Some applications are insensitive to the document type, others are acutely aware of it. But I'm digressing... An SGML mode, to me, is a mode which does not work on the DTD-specific level, but only helps the user make a valid SGML document. I think that if a mode is cognizant of any specific DTD, that means it also has to be aware of something about the processing that the document may undergo -- something outside of SGML. Conversely, if a mode does not have any extra-SGML-ular knowledge, the difference between one mode which is DTD-specific and one which is not, is that the former is a poorly written version of the latter, because there is nothing which the generality would make you compromise. Given these arguments, I don't see any point in making DTD-specific modes, and lots of value in making one for SGML documents in general. | You could handle SHORTREF (and other problems you raised) with | alternate keymaps that get used as you move around (I don't recall how | efficient this would be in the current implementation of GNU Emacs, but | I could do this with a Tk-based editor with very little problem). This would make it exceedingly hard to identify SHORTREFs consisting of more than one character, especially when entered separated by other key-strokes. It also defeats the purpose of SHORTREFs. If you want abbreviations and typing help, GNU emacs already has ample support for that. I see no conflict between these and editing/keyboarding SGML. It must be remembered that text is not entered in a linear fashion, but is subject to incomplete tasks (e.g., half a tag), typos, their correction, with movements all over the place as part of the editing. It's therefore very important that as little state information as possible is kept by the mode. In most existing modes, there is no state information at all, but rather large amounts of computation whenever a task is completed. This will not work easily with SGML, since the tasks are much more complex. (E.g., in the C mode, a `:' is "electric" in that it looks around to see what kind of `:' it is, and does a number of different things accordingly, such as change the indentation of the current line, etc. In SGML, we have both the matching pairs (`<',`>'), (`') on the lexical level, and (start-tag, end-tag) on the syntactical level, as well as the asynchronous marked sections. Now add minimization and short references. It's probably possible to make a state-less mode, but it will eat a lot of CPU power. I'm not sure that would be a good idea. Sometimes, I'm not even sure it _is_ possible, because, as I mentioned previously, parsing SGML backwards is a pain in the rear.) | So, there would be two parts to this hypothetical editing system (GNU | Emacs mode, Tk widgets, BOS objects (an OOPL I have prototyped in Tcl), | whatever): a DTD-independent, generic library of routines that the | DTD-specific "modes" (or whatever you want to call them) use. You'll get a long way with this approach, but my own experimentation tells me that you don't get far enough, and a mode like this will have to "fake" the parsing process if it doesn't do it properly. I have some pretty silly elisp code which finds the matching `<' for a `>', as well as the matching start-tag for an end-tag, and code to skip over elements, etc. They work as long as no information about the elements is required, and you need that with SHORTREF, with empty elements, with other forms of declared content, and especially with minimization. The problem can be condensed as follows: Canonical form SGML is very easy to parse, but it's so hard to type in that _that_ is precisely what we wish the computer to help us do, and then it's not at all easy to parse, any more. Some editors I've seen don't allow you to enter parts of a tag, for instance, and put them together so it looks like a tag, indeed is a tag, but instead force you to work with complete tags, even complete elements. This is undoubtedly because of the problems inherent in constantly looking over your shoulder to see if the world you thought you knew suddenly changed, as well as the unlimited set of error conditions users can create if you allow them this level of freedom. However, GNU Emacs is all about freedom to do what you want, and we can't make a braindead, limping mode akin to some "word processors" for Emacs users. They came to Emacs because they wanted freedom and power. We will have to give them more power and not take away their freedom. ("Freedom to use the power," that is, as opposed to "freedom to create it," but that is another discussion.) I don't intend to take away the joy of making a DTD-specific mode, as I'm sure that can be done with relative ease, if only part of SGML is to be supported. Providing help and guidance with writing canonical form SGML with constraints on the content models of elements, would also be relatively easy. As long as a parser can be used to validate the resulting document, and return useful error messages, there might not be a need for a mode-cum-parser. I still think it would be a lot more cool to do that, though. I've spent enough time tinkering with other Emacs modes to want to relieve the users of a mode of the same pains. But if you can make it fly, go for it. We have sendmail all over the place and it's a piece of s**t, but it sure gets a lot of mail there. Best regards, \ -- Erik Naggum | +47-295-0313 | ISO 8879 SGML | Memento, Naggum Software | | DIS 10744 HyTime | terrigena. Boks 1570, Vika | \ | JTC 1/SC 18/WG 8 | Memento, 0118 OSLO, NORWAY | \ | SGML UG SIGhyper | vita brevis. Newsgroups: comp.text.sgml Date: 19 Mar 1992 18:43:47 UT From: Sean Levy \ Organization: Carnegie Mellon, Pittsburgh, PA Message-ID: <0dmC3Xu00hMg4iPJ8h@cs.cmu.edu> References: <1992Mar16.152312.20696@epas.toronto.edu> <23055B@erik.naggum.no> \ \ <23057C@erik.naggum.no> Subject: Re: sgml-mode for emacs? [ I've not crossposted this to comp.emacs because I have a feeling those folks are getting tired of this discussion. Given the normal content of the posts there, I'm sure 90% of the readership has NO IDEA what the hell we are talking about --S ] Your arguments against DTD-specific tools are, in general, valid, but you don't quite understand where I am coming from. I decided against a discussion of this in my previous post because it had nothing to do with the specific issue at hand, but now... The environment that I am working on (called n-dim), and which I have a prototype for now, is a generalized (excuse the pun) information modeling environment, to which there are three conceptual levels (please note that my project is coming at this problem from the point of view of providing a support system for designers, particularly engineering design people, but not at all limited to that context). At the bottom, we have models, which can be considered "instances" in a sort of generic way. Examples of models are functional decompositions, equational descriptions and other sorts of analysis-type models, issue-based negotiation models (ala gIBIS), project models, task-asignment models, document-flow models, and "untyped", or Universal models. All models are instances of a particular Modeling Language, e.g. the Negotiation ML, the FunctionDecomposition ML, etc. An ML consists, conceptually, of three parts: a representational paradigm that defines the space of possible models in this langauge, an operational component that defines what operations are possible on models in this language and sets of rules that work, in various ways, to define the space of meaningful models within the space of possible ones. Modeling Languages are also Models, similar to (but not the same as) the way that Classes are also Instances in some OOPLs. The representational paradigm of an ML is given (modeled) in terms of node types, link types and rules for constructing valid models from these elements. For instance, a subset of the NegotiateML might look (conceptually) like: Node types: Issue, Answer, Argument Link types: subissue, has-answer, has-argument-for, has-argument-against Grammar: Issue -subissue-> Issue Issue -has-answer-> Answer Answer -has-argument-for-> Argument Answer -has-argument-against-> Argument If one created a Model in this language, one would be able to put into it only nodes of type Issue, Answer or Argument, and create links between them in the specified ways given above (I have greatly simplified for the purposes of example). I should interject here that this environment (n-dim) is a multi-user, graphical environment, in which models are presented to the user (by default) in a boxes-and-arrows notation (there are other sorts of presentations, but nevermind). One level above MLs is what we call MLL, the Modeling Language Language. It is a set of facilities for creating MLs, in a nutshell. There is MUCH to this -- much more, perhaps than meets the casual eye. My purpose here, however, is just to lay down enough context so that I can explain what role I see SGML (and HyTime) playing in this environment. ML builders are, as far as we are concerned, building Models, but special kinds of models. They have the same graphical interface to building MLs that they do to building Models, but have access to some facilties (MLL) that are not normally needed to build Models, like writing oprerations (code, interfaces to external computational entities, whatever). It occured to me as I starting looking into SGML that an n-dim ML could be mapped, conceptually, onto an SGML DTD and that Models could likewise be mapped onto instances of that DTD. There are a couple contexts in which this could be done, for achieving different purposes. Since all node-types resolve down, at the leaves, to text or strings of bits (pictures, sound, what have you), one could use SGML as a linear representation of a (by nature non-linear) model. There are other implications, but, again, nevermind. Now, we have the ML builder happily building along. Clearly, we could put in MLL facilties for allowing the building up of an SGML DTD "in parallel" with the creation of the ML. Some parts of this "allowing" could be fairly mechanical, others would be more in the form of giving the ML builder a convenient way to edit (parts of the DTD) as he went along. So, from my point of view, my users are not at all concerned with SGML. They are designers, engineers, managers,etc. who are structuring, capturing and managing various forms of information in this environment. SGML would, from their point of view, provide the facilities that allow things like making printed representations of models, using models in the creation of documents, etc. Clearly, the need for an SGML editing system still exists (although I think I can achieve large parts of that in n-dim with the facilities I have outlined so far, but that is a different story). To paraphrase my post on SGML in response to a question on comp.emacs: n-dim is a big idea. I have only outlines some pieces of it. I could summarize this post by saying that we have a vision of an overarching but non-limiting information modeling/management environment and that SGML et al seems like it should play a role in it. But our focus is not on things like SGML editors, but on higher-level tools, although it is obvious that, at some point, an editor that makes it easier to deal with SGML is highly desireable. So, I am not really concerned about whether or not an editing mode is DTD-dependent or not, since from my point of view it is. Does this make more sense? Cheers, -- Sean -- Sean Levy | n-dim Group / Engineering Design Research Center snl+@cs.cmu.edu | Carnegie Mellon University +1 412 268 5226 | 5000 Forbes Ave / Pittsburgh, PA / 15221 Newsgroups: comp.text.sgml Date: 19 Mar 1992 19:16:13 UT From: tvh@gnv.ifas.ufl.edu Message-ID: <1992Mar19.141613.946@gnv.ifas.ufl.edu> Subject: Re: SGML Parsers I understand there are public domain sgml parsers available for dtd and instance testing purposes. Any ideas where one could be located? Thanks! Tony H. Newsgroups: comp.text.sgml Date: 19 Mar 1992 21:56:08 UT From: Robert Chann <454rchan@qucis.queensu.ca> Organization: Computing & Information Science, Queen's University Message-ID: <1992Mar19.215608.13245@qucis.queensu.ca> Keywords: miscellaneous questions, SGML, general information Subject: Miscellaneous questions about SGML (fairly long) I'm posting this for a friend who doesn't have net access. Please send e-mail replies directly to me. Thanks very much in advance! 1) What other "markup languages" (besides SGML) are available and who "manufacture" them? (Both "internal-use-only" and commercially available MLs, I guess.) 2) Is there a language that "set the standard" for others, say, a few years ago? How much "more advanced" is this language now? 3) How do the currently available packages compare in the following areas: a) technology b) reliability c) price d) user-friendliness (I apologize for the HEAVY use of double-quotes. The guy who sent me these questions is not very familiar with markup languages and is not exactly a computer type.) :) I think pointers to easy-to-understand review articles in, for example, Byte, MacWorld, UnixWorld or PC World would be useful. BTW, please send me replies for the above questions ASAP. Now, for my own curiosity (hopefully these questions will make a little bit more sense): 1) WHAT IS SGML? Is it like LaTeX or troff or GML (I think that's what I used when I was working at IBM as a co-op student 3-4 years ago)? 2) Is SGML an industry standard, like JPEG or MPEG? 3) Is SGML for DOS, UNIX, CMS or all of them? 4) Can I get it free from an FTP site? (Free? Hah!) Are companies giving out demo disks (for DOS)? 5) How widespread is the use of SGML? My understanding is that LaTeX is used by MANY people in North American universities (please correct me if I'm wrong). Is SGML going to replace LaTeX in the near future? (Please, no!) These questions probably sound really stupid to those of you who know SGML (or markup languages in general) very well. Is there an FAQ for this newsgroup? I think an FAQ would definitely help me understand this whole SGML business! Thanks very much for reading this article. I'm looking forward to receiving replies from you. -- ============================================================================= Robert Chann Queen's University Phone: (613)545-6693 Kingston, Ontario, Canada Email: rchann@eleceng.ee.queensu.ca Newsgroups: comp.text.sgml Date: 19 Mar 1992 21:58:47 UT From: Robert Chann <454rchan@qucis.queensu.ca> Organization: Computing & Information Science, Queen's University at Kingston Message-ID: <1992Mar19.215847.13335@qucis.queensu.ca> Subject: Miscellaneous questions about SGML (fairly long) (I apologize if this article gets sent twice.) I'm posting this for a friend who doesn't have net access. Please send e-mail replies directly to me. Thanks very much in advance! 1) What other "markup languages" (besides SGML) are available and who "manufacture" them? (Both "internal-use-only" and commercially available MLs, I guess.) 2) Is there a language that "set the standard" for others, say, a few years ago? How much "more advanced" is this language now? 3) How do the currently available packages compare in the following areas: a) technology b) reliability c) price d) user-friendliness (I apologize for the HEAVY use of double-quotes. The guy who sent me these questions is not very familiar with markup languages and is not exactly a computer type.) :) I think pointers to easy-to-understand review articles in, for example, Byte, MacWorld, UnixWorld or PC World would be useful. BTW, please send me replies for the above questions ASAP. Now, for my own curiosity (hopefully these questions will make a little bit more sense): 1) WHAT IS SGML? Is it like LaTeX or troff or GML (I think that's what I used when I was working at IBM as a co-op student 3-4 years ago)? 2) Is SGML an industry standard, like JPEG or MPEG? 3) Is SGML for DOS, UNIX, CMS or all of them? 4) Can I get it free from an FTP site? (Free? Hah!) Are companies giving out demo disks (for DOS)? 5) How widespread is the use of SGML? My understanding is that LaTeX is used by MANY people in North American universities (please correct me if I'm wrong). Is SGML going to replace LaTeX in the near future? (Please, no!) These questions probably sound really stupid to those of you who know SGML (or markup languages in general) very well. Is there an FAQ for this newsgroup? I think an FAQ would definitely help me understand this whole SGML business! Thanks very much for reading this article. I'm looking forward to receiving replies from you. -- ============================================================================= Robert Chann Queen's University Phone: (613)545-6693 Kingston, Ontario, Canada Email: rchann@eleceng.ee.queensu.ca Newsgroups: comp.text.sgml,comp.emacs Date: 19 Mar 1992 23:11:00 UT From: "Carla K. Corkern" \ Organization: Ericsson Network Systems Message-ID: <1992Mar19.231100.8990@exu.ericsson.se> References: <1992Mar16.152312.20696@epas.toronto.edu> <23055B@erik.naggum.no> \ Subject: Re: intro SGML books >Eric says: >It is therefore with significant discomfort that I do not commend any >other book on SGML on the market today. Has anyone else been favorably impressed with "THE SGML PRIMER" from SoftQuad? I've had good results using it as an initiation tool in my group. Carla Newsgroups: comp.text.sgml Date: 20 Mar 1992 13:17:19 UT From: ""Dr. "Eliot Kimber" Macro"" \ Message-ID: <9203201330.AA17829@ucbvax.Berkeley.EDU> Subject: SGML and LaTeX An SGML tag language and LaTeX are similar in that the tags in an SGML tag language describe document elements (paragraphs, headings, etc), and LaTeX also has macros for identifying document elements (\\chapter, \\section, \\para, etc.). However, LaTeX is a document processing and formatting system, while an SGML tag language is simply a text description language--it doesn't do anything by itself, but requires some processing application to do something useful with it. LaTeX does not make a clear distiction between element identification and processing functions (in other words, there is no syntactic difference in LaTeX between the \\section macro and the \\obeycr macro), while SGML makes a clear distinction between element identification (tags) and processing functions (formatter macros, C routines, etc.). It turns out, in fact, the LaTeX and SGML tag languages for print documents make a good match, because an SGML application can easily map SGML tags to sets of LaTeX macros, i.e.: \

This is a Heading maps to \\chapter{This is a Heading} The advantage of SGML over LaTeX for this sort of application is that my SGML source, being separated from the processing function, can be used for other things (for example, I could also translate it to DCF macros for printing with IBM's document composition facility, or run a process to do database extraction from the source), while LaTeX documents are pretty much limited to processing with TeX. SGML won't replace LaTeX. In fact, SGML creates a need for LaTeX because LaTeX is such an easy way to implement the printing of SGML documents. I would, in fact, expect to see LaTeX extended to support the needs of new SGML-based applications, or if not LaTeX specifically, the development of other TeX formats designed for use with specific SGML document types. Eliot Kimber Internet: drmacro@ralvm13.vnet.ibm.com Dept E14/B500 IBMMAIL: USIB2DK9@IBMMAIL Network Programs Information Development Phone: 1-919-543-7091 IBM Corporation Research Triangle Park, NC 27709 Newsgroups: comp.text.sgml Date: 20 Mar 1992 19:48:37 UT From: Larry Baum \ Organization: Boeing Computer Services Message-ID: <69376@bcsaic.UUCP> References: <1992Mar12.155828.16971@apollo.hp.com> Subject: Re: Do FrameMaker or Interleaf convert to SGML? In article <1992Mar12.155828.16971@apollo.hp.com> kotwal@apollo.hp.com (Marilyn Kotwal) writes: >Is there any way to convert Interleaf versions 4 or 5 or FrameMaker 3.0 >documents to an SGML format? > >-Marilyn Kotwal > Not without a lot of programming! Newsgroups: comp.text.sgml,comp.emacs Date: 20 Mar 1992 20:27:12 UT From: Marcia Hoppers \ Organization: Intergraph Corporation, Huntsville, AL. Message-ID: <1992Mar20.202712.22342@infonode.ingr.com> References: <1992Mar16.152312.20696@epas.toronto.edu> <23055B@erik.naggum.no> <1992Mar19.231100.8990@exu.ericsson.se> Subject: Re: intro SGML books In article <1992Mar19.231100.8990@exu.ericsson.se>, exuckc@exu.ericsson.se (Carla K. Corkern) writes: > Has anyone else been favorably impressed with "THE SGML PRIMER" from SoftQuad? > I've had good results using it as an initiation tool in my group. > > Carla Yes, it is a good, brief introduction to SGML -- not so much for programming/ support purposes but it fills the need for a good introduction for the enduser. _____________________________________________________________________________ | Marcia Hoppers | Corporate _ ___ _ | | | INTERGRAPH, Huntsville, AL | Publication / ) (/)( | Purgamentum init, | | hoppersm@infonode.ingr.com | Services (_ / _) | exit purgamentum. | |________________|_|_______| Newsgroups: comp.text.sgml Date: 21 Mar 1992 06:02:44 UT From: "david l. martin" \ Organization: UCLA Computer Science Department Message-ID: <1992Mar21.060244.5301@cs.ucla.edu> Subject: SGML and source code My impression is that SGML is used primarily for marking up text for purposes of publication and documentation. But I'm very curious to know if anyone has used an SGML tag language for marking up source code - in C, Ada, Fortran, Lisp, or whatever. For example, marked-up source code could be useful as input to a pretty-printer or a structured editor. If anyone has done this, I'd be very interested in hearing about it and seeing how it was defined. Thanks. Dave Martin C.S. Dept. UCLA Newsgroups: comp.text.sgml Followup-To: comp.text.sgml Date: 21 Mar 1992 18:21:45 UT From: Jeff Lankford \ Reply-To: jlankford@nrtc.northrop.com Organization: Northrop Research and Technology Center Message-ID: <36276@gremlin.nrtc.northrop.com> References: <9203201330.AA17829@ucbvax.Berkeley.EDU> Keywords: SGML, TeX, LaTeX Subject: Re: SGML and LaTeX In article <9203201330.AA17829@ucbvax.Berkeley.EDU>, DRMACRO@RALVM13.VNET.IBM.COM ("Dr. "Eliot Kimber" Macro") writes: ... a bunch of stuff about SGML and LaTeX deleted ... |> LaTeX does not make a clear |> distiction between element identification and processing functions |> (in other words, there is no syntactic difference in LaTeX between |> the \\section macro and the \\obeycr macro), while SGML makes a |> clear distinction between element identification (tags) and |> processing functions (formatter macros, C routines, etc.). |> It turns out, in fact, the LaTeX and SGML tag languages for |> print documents make a good match, because an SGML application |> can easily map SGML tags to sets of LaTeX macros, i.e.: |> \
This is a Heading |> maps to |> \\chapter{This is a Heading} ... more deleted stuff ... |> I would, in fact, expect to see LaTeX |> extended to support the needs of new SGML-based applications, |> or if not LaTeX specifically, the development of other TeX formats |> designed for use with specific SGML document types. The point of the article was unclear, but my impression is the evaluation of the relation of SGML to LaTeX was muddled. This article is intended to provided brief clarification of: 1) relation of TeX to LaTex, 2) historical and current work involving TeX and SGML, 3) my opinion of the relation of SGML to TeX and other format languages. TeX is a typesetting language developed by Don Knuth at Stanford in the 1970's to help him prepare for publication his series of mathematically oriented books, "The Art of Computer Programing". TeX has a large number (about three hundred) of primitive operators (add, subtract, ...) suitable for general purpose programing use, as well as specialized operators. TeX provides general purpose macro processing with [limited number of positional (!)] argument substitution for defining new operators or redefining existing operators. Data types are fairly limited (but also redefinable). Typically, TeX applications are bin packing problems, such as laying out text on a two dimensional page. TeX systems work by fitting little boxes into larger boxes according to the rules of its current states; TeX has few states/modes (vertical, horizontal, math, ...), but packing rules can vary significantly. Rules are embedded in the TeX processor, but their effects are modified by parameters supplied in the form of operators or variables. TeX ditinguishes between input operators and input text; it separates input text into fine pieces (characters) and puts them into boxes, then in nested groups of boxes and so forth, based on psuedo-English composition rules (characters, syllables, words, sentences, pargraphs, ...) for specified container restrictions (line length, page length, ...). LaTeX is a macro package written in TeX by Leslie Lamport in the mid-1980's. Essentially it simplies raw TeX by codifying some commonly used code sequences (such as two-column format). However, it is an organized collection of macros based on document styles (analogous to DTD's); document style affects the behavior of macros, since certain macros may become illegal or change processing in given style contexts. All the power of TeX is available by direct use of TeX primitives. A good deal has been accomplished in integrating TeX and SGML --- after all SGML is pretty useless without some sematics provided by an external processor. Thomas Gordon used the Amsterdam parser to build an SGML to LaTeX translator a few years back; i believe Tom announced public availability of the translator in this newsgroup some time ago. The main weakness was the rudimentary nature of the SGML-to-LaTeX mapping formalism, though it might be argued that is a strength. Stronger formalism was recently described by Andrew Dobrowski in "Typesetting SGML Documents using TeX" (TUGboat, December 1991). Essentially, FOSI is used to provide a specification language for defining TeX macros, which are then used to process (slightly) reformated SGML source documents, for example "\" becomes "\\title" and "<\\para>" becomes "\\endpara". Dr. Macro's example is reasonably expanded from \<h1>Chapter Title<\\h1> becomes: \\chapter{Chapter Title} to \<h1 justify=center font=bold>Chapter Title<\\h1> where `justify' and `font' are attributes useful to formatting processors and probably ignored by other processors. becomes: \\newcommand{\\h1}[2]{ ...command defined using (La)TeX with 2 parameters ...} \\newcommand{\\h1end}{ ...command defined with no arguments ...} \\h1{center}{bold}Chapter Title\\h1end Note that `\\newcommand` usage here is some combination of SGML ELEMENT, ATTRIBUTE, and ENTITY definitions (not shown). Winner of clarity and elegance award is a tossup in this example. Dr. Macro objects to LaTeX on the grounds that objects and functions are manipulated using a non-distinguishing syntax, in contrast to SGML, in which \<object> is syntactically distinguished from \<?process>. In my religion, we respect the religious beliefs of others (in public), but we laugh (in private) at those practicing idolatry and iconography, since we know simplicity is best. For example, we know that APL, Lisp and TeX are much more spiritual than COBOL and SGML, and being more spiritual, they are eminently, manifestly easier to manipulate on the material plane as well. Finally, Dr. Macro observes that SGML will not replace LaTeX, which is heartening for those who make productive use of TeX. The observation that LaTeX will change as a result of SGML influence is promising. Many users of TeX/LaTeX are rotten programmers who faily miserably to modularize, using the provided mechanisms. If SGML conceptual distinction between object and action is better adopted in the TeX domain, that would be a big win; syntactic distinctions are meaningless and annoying. Dobrowski's work is a powerful step in the right direction. jpl </message> <message id="<1992Mar23.100526.1@idicl1.idi.battelle.org>" date="2910351926"> Newsgroups: comp.text.sgml Date: 23 Mar 1992 15:05:26 UT From: rwood@idicl1.idi.battelle.org Organization: IDI-Dublin Message-ID: <1992Mar23.100526.1@idicl1.idi.battelle.org> References: <1992Mar16.152312.20696@epas.toronto.edu> <23055B@erik.naggum.no> <1992Mar19.231100.8990@exu.ericsson.se> <1992Mar20.202712.22342@infonode.ingr.com> Subject: Re: intro SGML books In article <1992Mar20.202712.22342@infonode.ingr.com>, hoppersm@infonode.ingr.com (Marcia Hoppers) writes: > In article <1992Mar19.231100.8990@exu.ericsson.se>, exuckc@exu.ericsson.se (Carla K. Corkern) writes: >> Has anyone else been favorably impressed with "THE SGML PRIMER" from SoftQuad? >> I've had good results using it as an initiation tool in my group. >> >> Carla > > Yes, it is a good, brief introduction to SGML -- not so much for programming/ > support purposes but it fills the need for a good introduction for the enduser. Would anyone happen to have an address or phone number for SoftQuad handy? Rich Wood Information Dimensions, Inc. 5080 Tuttle Crossing Blvd. Dublin, Ohio 43017 </message> <message id="<1992Mar23.152245.2812@wam.umd.edu>" date="2910352965"> Newsgroups: comp.text.sgml,comp.dcom.lans.mis,comp.dcom.lans,comp.misc Date: 23 Mar 1992 15:22:45 UT From: "Mario A. Cole" \<macole@next09csc.wam.umd.edu> Organization: Workstations at Maryland, University of Maryland, College Park Message-ID: <1992Mar23.152245.2812@wam.umd.edu> Subject: Info about VANs Hello all, I'm looking for any type of information on Value Added Networks. As of now, I don't know anything about this; I would appreciate any type of information or references. I'm also looking for information on EDI (Electronic Data Interchange) systems and some info on CALS (forgot what that stands for). thanks, mario -- Mario A. Cole | HJ Ford Associates |"A faithful friend is the Univ. of Maryland | Crystal City | medicine of life." macole@wam.umd.edu | Arlington, VA | H: (301) 868-9249 | W: (703) 553-5580 | ECCLESIASTICUS 6:16 </message> <message id="<9203231819.AA01327@ucbvax.Berkeley.EDU>" date="2910356830"> Newsgroups: comp.text.sgml Date: 23 Mar 1992 16:27:10 UT From: ""Dr. "Eliot Kimber" Macro"" \<DRMACRO@RALVM13.VNET.IBM.COM> Message-ID: <9203231819.AA01327@ucbvax.Berkeley.EDU> Subject: Interleaf to SGML >Is there any way to convert Interleaf versions 4 or 5 or FrameMaker 3.0 >documents to an SGML format? > >-Marilyn Kotwal > The problem is that there is no standard set of Interleaf components nor is there a standard set of SGML tags, so a truly general Interleaf-to-SGML translator is more or less impossible (discounting AI systems). However, if your authors have used a consistent set of Interleaf components, it's not too hard to write converters that will do as good a job as can be done. The real problem is that Interleaf components don't necessarily (and almost never are designed to) identify document structure to the degree needed for translation to SGML languages. For example, say I create a List Item component, but no List Start or List End components (which would generally be useless in Interleaf since it doesn't care about structure anyway). How do I know where a list starts? Where does it end? What does a list item contain? About the only clues I have are format specifications like indention. My experience writing translators from Interleaf to SGML is that, given a set of components that maps fairly closely to your target tag set, the best you can achieve is about 90% complete conversion. If your components are very general and largely format specifications, rather than element identifiers, your conversion will be much more limited, say 70% at best. Eliot Kimber Internet: drmacro@ralvm13.vnet.ibm.com Dept E14/B500 IBMMAIL: USIB2DK9@IBMMAIL Network Programs Information Development Phone: 1-919-543-7091 IBM Corporation Research Triangle Park, NC 27709 </message> <message id="<1992Mar24.034943.21594@msen.com>" date="2910397783"> Newsgroups: alt.wais,comp.text.sgml Date: 24 Mar 1992 03:49:43 UT From: Edward Vielmetti \<emv@msen.com> Organization: MSEN, Inc. -- Ann Arbor, MI Message-ID: <1992Mar24.034943.21594@msen.com> References: \<chumphre.701387866@seymour> Keywords: wais, pat Subject: Re: search engines and comparisons In article \<chumphre.701387866@seymour> chumphre@seymour.ucs.ualberta.ca (Chuck Humphrey) writes: >We are also curious to know about any comparisons between PAT and WAIS. >PAT is search software developed for use with the OED. I've used them both on the same text collection (more or less), so I guess I feel qualified to answer. The text collection is what's currently the "comp.archives" wais server; I didn't have a fully configured version of LECTOR going so I can't make 100% faithful comparisons. The text indexing that PAT does is quite good. Its "semi-infinite strings" approach (Patricia trees) provides a lot more precision at the fine scale level than WAIS's relatively simple inverted index has; it's no sweat at all to look for occurences of even a long phrase in PAT, whereas the WAIS approach tends not to handle focused queries with such ease. For the target document - the OED - PAT is quite well suited. With the "LECTOR" display software it will show the text quite as the original work does on paper, and it has been used with other dictionary and highly marked up texts to produce quite good results. On the other hand, for the set of texts I was working with (netnews articles, essentially) PAT was both overkill and underpowered. Overkill in the sense that it could pick out very fine minutiae of detail in the texts I was searching, but that it couldn't give the general fuzzy good/not good range of rankings which WAIS yields so reasonably. I got way too many cases where there were either 100 documents which matched my search or none at all. PAT is sufficiently powerful, and I believe that the interface is sufficiently general at the programming level, that it could be used as an engine for a Z39.50 server. To provide functions comparable to the existing PAT/LECTOR combo you'd need a WAIS client which understood how to properly display a structured (SGML) document, and some out of band communications about formatting. I know I'd like to see a WAIS server with the OED in it! But to be reasonable you'd want to build it on top of PAT rather than throw out the large index that's already there. (unless you have so much disk space that it's trivial to add another gig drive for an index) -- Edward Vielmetti, vice president for research, MSEN Inc. emv@msen.com MSEN Inc., 628 Brooks, Ann Arbor MI 48103 +1 313 741 1120 "Not to panic. Networking will eventually get to Michigan. Remember the decades it took IBM to discover virtual memory." Randy Bush </message> <message id="<1992Mar24.073931.16933@bohra.cpg.oz.au>" date="2910411571"> Newsgroups: comp.text.sgml Date: 24 Mar 1992 07:39:31 UT From: Elvis Leung \<leunge@bohra.cpg.oz.au> Organization: Computer Power Software Message-ID: <1992Mar24.073931.16933@bohra.cpg.oz.au> Subject: SGML Book Someone mentioned a book called "SGML Primer" earlier in this group. Could someone post me the title, the author and/or the pubisher. Anyone have any comments on this book? -- -------------------------------------------------------------------------------- Sek-Kit E. Leung Fax: +61-6-2836860 Computer Power Software Voice: +61-6-2836777 Multimedia Research Group ACSnet: leunge@bohra.cpg.oz.au </message> <message id="<1992Mar24.171135.28539@cis.ohio-state.edu>" date="2910445895"> Newsgroups: comp.text,comp.text.sgml,comp.text.tex Date: 24 Mar 1992 17:11:35 UT From: Sandy Mamrak \<mamrak@cis.ohio-state.edu> Organization: The Ohio State University, Department of Computer and Information Science Message-ID: <1992Mar24.171135.28539@cis.ohio-state.edu> Subject: Release of translation software ICA Release 1.2 24 March 1992 We are pleased to announce that a beta release of the Integrated Chameleon Architecture (ICA) is available for public distribution. The ICA is a toolset for generating data translators. In particular, the toolset can be used to generate translators to and from a constrained subset of instances of SGML Document Type Definitions (DTD). There are several example translators included. The first is a book DTD and includes specific translators for the LaTeX book documentstyle and a specific troff macro package. The second is a bibliographic DTD and includes specific translators for BibTeX and refer bibliographic database formats. Please note that the ICA is for developing translators and not providing translators. The ICA runs in the Unix environment, using the X Window System for the basis of the graphical user interfaces. Unfortunately, there are many variations on the above so the following list fills in the details. The primary development platform is a Sun4 with SunOS 4.1.1 using X11R4 from MIT. The primary window manager used during development is tvtwm. Hardware OS X11 Release Window Manager ------------------------------------------------------- Sun4 SunOS 4.1.1 R4,R5 twm tvtwm mwm olwm HP 300 HPUX 8.0 R4 -- HP 700 HPUX 8.0 R4 -- Other configurations are supported on a best--effort basis. We believe this should work on many platforms however we do not have the facilities for testing such platforms. The distribution is located on archive.cis.ohio-state.edu (128.146.8.52) in pub/chameleon/ICA-1.2.tar.Z as a compressed tar file. The postscript documentation is in pub/chameleon/ICAdoc-1.2.tar.Z. The postscript is split into several smaller files. The manual is 186 printed pages. A mailing list, ica@cis.ohio-state.edu, exists for those who would like to solicit and exchange ICA information. A list for reporting bugs has also been established. Details are given below. ---------------------------------------------------------------------- FTPing the ICA Toolset ---------------------------------------------------------------------- example% ftp ftp.cis.ohio-state.edu Connected to archive.cis.ohio-state.edu. 220 archive FTP server (SunOS 4.1) ready. Name (ftp.cis.ohio-state.edu:cso): anonymous 331 Guest login ok, send ident as password. Password: <--- Use your login name 230 Guest login ok, access restrictions apply. ftp> cd pub/chameleon 250 CWD command successful. ftp> binary <--- Just to make sure 200 Type set to I. ftp> get ICA-1.2.tar.Z <--- This will take time 200 PORT command successful. ftp> quit 221 Goodbye. example% <--- Back home example% uncompress ICA.tar.Z example% tar xvof ICA.tar <--- Untarring... Read the INSTALLATION_NOTES for further instructions on compiling ICA. Please read the COPYRIGHT notice. A subdirectory of example specifications for a simple article, book and bibliography is included in the distribution. ---------------------------------------------------------------------- FTPing the ICA Documentation ---------------------------------------------------------------------- The documentation is available in Postscript format. Alternatively, the documentation can be obtained by sending an email request to jenkins@cis.ohio-state.edu for the OSU Technical Report OSU-CISRC-1/92-TR3, `Technical Documentation for the Integrated Chameleon Architecture,' by S. A. Mamrak, C. S. O'Connell and J. Barnes. Please include a POSTAL mailing address to expedite the response to this request. To ftp the postscript form of the documentation, change to a directory, such as /usr/tmp, with plenty of free space. example% ftp archive.cis.ohio-state.edu Connected to archive.cis.ohio-state.edu. 220 archive FTP server (SunOS 4.1) ready. Name (ftp.cis.ohio-state.edu:cso): anonymous 331 Guest login ok, send ident as password. Password: <--- Use your login name 230 Guest login ok, access restrictions apply. ftp> cd pub/chameleon 250 CWD command successful. ftp> get ICAdoc-1.2.tar.Z ftp> quit 221 Goodbye. example% <--- Back home example% uncompress ICAdoc-1.2.tar.Z example% tar xvof ICAdoc-1.2.tar <--- Untarring... Print out the files to your postscript printer with the appropriate command for your system. ---------------------------------------------------------------------- Subscribing to the ICA Mailing List ---------------------------------------------------------------------- Please direct all inquiries and comments concerning the ICA to the mailing list, ica@cis.ohio-state.edu, and not to any individuals. If you would like your name added to the ICA mailing list, please send email to ica-request@cis.ohio-state.edu, with subject line `ICA mailing list'. In the body of the message, please indicate the (internet) email address that you would like added to the list. The list is maintained manually, with updates every few days. ---------------------------------------------------------------------- Sending Bug Reports to the ICA Bug List ---------------------------------------------------------------------- If you find any bugs in the ICA, kindly report them by email to ica-bugs@cis.ohio-state.edu. A bug report form, BUG_REPORT, is available with the ICA distribution. Kindly use that report form to expedite bug handling. Good luck! The ICA crew -- Sandra A. Mamrak Department of Computer and Information Science The Ohio State University mamrak@cis.ohio-state.edu 2036 Neil Ave., Columbus, OH USA 43210-1277 </message> <message id="<1992Mar24.180706.224@decvax.dec.com>" date="2910449226"> Newsgroups: comp.text.sgml Date: 24 Mar 1992 18:07:06 UT From: Eve Maler UEG Doc \<maler@abyss.zk3.dec.com> Reply-To: maler@decvax.dec.com (Eve Maler UEG Doc) Organization: Digital Equipment Corporation - Nashua, NH Message-ID: <1992Mar24.180706.224@decvax.dec.com> References: <1992Mar24.073931.16933@bohra.cpg.oz.au> Subject: Re: SGML Book (While I'm writing this, the group will probably receive three other posts with the same information...) "The SGML Primer" is written and published by SoftQuad Inc. You can order copies from them (is this a current address?): 720 Spadina Avenue Toronto, Canada M5S 2T9 Telephone: +1 (416) 963-8337 I have the second edition. I was a little disappointed in this book -- I guess I was expecting a kind of "hardcopy FAQ" that I could hand to folks in my company, and it doesn't really fit the bill. For a quite small book, it seems like it's kind of daunting to read for absolute beginners, being chock full of DTD code and keywords. It mixes up the two different tasks of coding a DTD and coding an instance, and doesn't step back to see the big picture as much as it should. (However, whenever I forget the official names of delimiters etc., I look at its back cover, which has them all laid out graphically...) In short, I think end-user beginners won't quite find what they're looking for after they wade through the Primer, but parts of it can serve as a quick reference for the more knowledgeable. Eve Maler Digital Equipment Corporation maler@decvax.dec.com </message> <message id="<24MAR199217255722@adpdp2.lanl.gov>" date="2910471900"> Newsgroups: comp.text.sgml Date: 25 Mar 1992 00:25:00 UT From: sandoval_perry <108101@adpdp2.lanl.gov> Organization: Los Alamos National Laboratory, EMVAX Message-ID: <24MAR199217255722@adpdp2.lanl.gov> Keywords: SGML-ouput, French-source-text Subject: SGML query and French source text. I have two requests, only vaguely related to each other. 1) I have recently downloaded the sgml stuff from the University of Exeter. VM2, the parser, seems to work fine but I am unsure of what it's output is supposed to be. It seems that all it does is check the sgml source against a dtd and say yes it's good or no it's not. I'm desparately trying to get some things going in sgml. I have to display tons of information on VT100 terminals, IBM proprinters, HP laser printers, and PostScript printers. First translating the source data in sgml seems the best way to go. But once I have it in sgml where do I go to format it appropriately for these different outupt devices? I've programmed a lot of text utilities, so before I go off and write a parser, or formatter, or whatever I'd like to know more. Suggestions greatly appreciated. 2) I spent a lot of time trying to learn French in college, unfortunately there are not very many Francophones here in the moutains of the great southwest. I really want and need the practice. Are there any French Internet sites? French news groups? Il faut que je pratique le francais. Perry Sandoval sandoval_perry@allin1.adpdp2.lanl.gov Los Alamos National Laboratory C programmer assigned to support technical writers, Database administator. :-) </message> <message id="<CSO.92Mar25121909@dolphin.hal.com>" date="2910543549"> Newsgroups: comp.text.sgml Date: 25 Mar 1992 20:19:09 UT From: Conleth O'Connell \<cso@hal.com> Reply-To: cso@hal.com (Conleth O'Connell) Organization: HaL Computer Systems Message-ID: \<CSO.92Mar25121909@dolphin.hal.com> References: <9203231819.AA01327@ucbvax.Berkeley.EDU> Subject: Re: Interleaf to SGML In article <9203231819.AA01327@ucbvax.Berkeley.EDU> DRMACRO@RALVM13.VNET.IBM.COM ("Dr. "Eliot Kimber" Macro") writes: Path: hal.com!decwrl!mips!spool.mu.edu!agate!ucbvax!RALVM13.VNET.IBM.COM!DRMACRO From: DRMACRO@RALVM13.VNET.IBM.COM ("Dr. "Eliot Kimber" Macro") Newsgroups: comp.text.sgml Date: 23 Mar 92 16:27:10 GMT Article-I.D.: ucbvax.9203231819.AA01327 Sender: usenet@ucbvax.BERKELEY.EDU Lines: 33 >Is there any way to convert Interleaf versions 4 or 5 or FrameMaker 3.0 >documents to an SGML format? > >-Marilyn Kotwal > The problem is that there is no standard set of Interleaf components nor is there a standard set of SGML tags, so a truly general Interleaf-to-SGML translator is more or less impossible (discounting AI systems). However, if your authors have used a consistent set of Interleaf components, it's not too hard to write converters that will do as good a job as can be done. The real problem is that Interleaf components don't necessarily (and almost never are designed to) identify document structure to the degree needed for translation to SGML languages. For example, say I create a List Item component, but no List Start or List End components (which would generally be useless in Interleaf since it doesn't care about structure anyway). How do I know where a list starts? Where does it end? What does a list item contain? About the only clues I have are format specifications like indention. My experience writing translators from Interleaf to SGML is that, given a set of components that maps fairly closely to your target tag set, the best you can achieve is about 90% complete conversion. If your components are very general and largely format specifications, rather than element identifiers, your conversion will be much more limited, say 70% at best. Eliot Kimber Internet: drmacro@ralvm13.vnet.ibm.com Dept E14/B500 IBMMAIL: USIB2DK9@IBMMAIL Network Programs Information Development Phone: 1-919-543-7091 IBM Corporation Research Triangle Park, NC 27709 The same problem holds true in Frame too. Complicated of course by nesting lists within lists as well. It interesting to note that the "ancient" batch oriented text formatters like troff, LaTeX, and even the young Lout, all provide this information quite easily with their explicit list environments. The rumor mills have it that Frame will be supporting SGML by the end of this year. I can't wait to find out what that really means! Cheers, Con -- Conleth O'Connell Email: cso@hal.com HaL Computer Systems, Inc. Phone: (512) 794-2855 8920 Business Park Drive, Suite 300 Fax : (512) 794-8737 Austin, Texas 78759 USA </message> <message id="<23066B@erik.naggum.no>" date="2910549184"> Newsgroups: comp.text.sgml Date: 25 Mar 1992 21:53:04 UT From: Erik Naggum \<erik@naggum.no> Reply-To: Erik Naggum \<enag@ifi.uio.no> Organization: Naggum Software, Oslo, Norway Message-ID: <23066B@erik.naggum.no> References: <1992Mar24.073931.16933@bohra.cpg.oz.au> <1992Mar24.180706.224@decvax.dec.com> Subject: Re: SGML Book Folks, I see that Robin Cover's bibliography is not getting the use it deserves. That's a real pity, since it's the best thing that happened to the SGML world after Goldfarb's Handbook. A quick look retrieves the following information: <39> SoftQuad, Inc. The SGML Primer. SoftQuad's Quick Reference Guide to the Essentials of the Standard: The SGML Needed for Reading a DTD and Marked-up Documents and Discussing them Reasonably. Version 2.0. Toronto: SoftQuad Inc., May 1991. 36 pages. Available from SoftQuad Inc.; 56 Aberfoyle Crescent, Suite 810; Toronto, Ontario; Canada M8X 2W4; TEL: +1 (416) 239- 4801; FAX: +1 (416) 239-7105. This is the correct address, phone number and all. The asterisk indicates high relative importance for beginners. However, I have to agree with Eve Maler, and I find considerable comfort in seeing someone else not being entirely happy with version 2.0, too. I had intended not say anything, since I always keep coming across as negative towards anything written on SGML that Goldfarb didn't write (joke, with lots of truth to it :-), but her assessment gets my full support. Version 2.0 is technically inaccuarate at important points. It lists such non-existent things as starting (or opening) literal delimiters and comment delimiters, and is misleading on empty elements (who have end-tags in their examples, illegal by the language), and many other smaller things, as well as some broader issues which don't get the treatment they should've gotten. The examples are not all valid SGML, either, and that's very close to a Sin in this business. However, it's light reading, and I think it does a relatively good job on what it was intended to accomplish, despite the technical inaccuracies, which are easy to fix. Last time I heard from SoftQuad, they told me that they had made a revision, and asked whether it was OK to include my name in the Ack's section, since they said they had listened to my complaints and those of several others. I had no problems with that, of course, and they said they'be sending me a copy. That's the last I heard from them on this. I'm surprised that somebody from SoftQuad has not come out and announced the availability of this new version now that people are practially begging for it. Are you there, SoftQuad? --------------------------------------------------------------------------- You can get the bibliography from the public FTP archive at ftp.ifi.uio.no in the file /pub/SGML/bibliography. Connect to ftp.ifi.uio.no [129.240.64.2], login as "ftp" or "anonymous", use your e-mail address as password, "cd" to "SGML", and retrieve the file "bibliography" in text mode or "bibliography.Z" in binary mode. --------------------------------------------------------------------------- Regards, \</Erik> -- Erik Naggum | +47-295-0313 | ISO 8879 SGML | Memento, Naggum Software | | DIS 10744 HyTime | terrigena. Boks 1570, Vika | \<erik@naggum.no> | JTC 1/SC 18/WG 8 | Memento, 0118 OSLO, NORWAY | \<enag@ifi.uio.no> | SGML UG SIGhyper | vita brevis. </message> <message id="<23066C@erik.naggum.no>" date="2910550916"> Newsgroups: comp.text.sgml Date: 25 Mar 1992 22:21:56 UT From: Erik Naggum \<erik@naggum.no> Reply-To: Erik Naggum \<enag@ifi.uio.no> Organization: Naggum Software, Oslo, Norway Message-ID: <23066C@erik.naggum.no> References: <24MAR199217255722@adpdp2.lanl.gov> Subject: Re: SGML query and French source text. sandoval_perry <108101@adpdp2.lanl.gov> writes: | | I have recently downloaded the sgml stuff from the University of | Exeter. VM2, the parser, seems to work fine but I am unsure of | what it's output is supposed to be. It seems that all it does is | check the sgml source against a dtd and say yes it's good or no | it's not. I'm desparately trying to get some things going in | sgml. I have to display tons of information on VT100 terminals, | IBM proprinters, HP laser printers, and PostScript printers. First | translating the source data in sgml seems the best way to go. But | once I have it in sgml where do I go to format it appropriately | for these different outupt devices? I've programmed a lot of text | utilities, so before I go off and write a parser, or formatter, or | whatever I'd like to know more. VM2 is only a markup validator. To access the parsed document, you would have to write a REXX application with the REXX interface tools provided, or write a C program with the vm2.c file as a example. I have done that, and it's fairly trivial. You can also use James Clark's "sgmls", which produces a line-oriented format which is relatively easy to parse with line-oriented Unix tools, such as perl. The first character of the line identifies the "type" of line, for instance. For larger applications, though, it's significantly less work to interface to ARC SGML than to sgmls, since you effectively have to make a (tiny) parser for sgmls's output. The significant enhancements that James Clark has made to sgmls over its base, ARC SGML, have to be considered, too. I'm working on fitting his enhancements back into ARC SGML. You'll find release 0.6 of sgmls in the sgmls directory at sgml1.exeter.ac.uk, or in /pub/SGML/ARC-SGML/jclark at ftp.ifi.uio.no, or in /pub/sgml/SGMLS at mailer.cc.fsu.edu. From here, I'm experiencing packet round-trip times of 1800 ms to sgmls1.ex.ac.uk, and 170 ms to the last router before I enter the UK! On the other hand, I see 500 ms round-trip times to mailer.cc.fsu.edu, so I guess you would benefit greatly from getting the files off either ftp.ifi.uio.no or mailer.cc.fsu.edu. (The reported times are averages over a dozen polls since sgml1.ex.ac.uk was reported live, with a standard deviation between polls of less than 10%.) In a separate article to follow this one, I have included listings of what's to be found at the different public FTP hosts. Best regards, \</Erik> -- Erik Naggum | +47-295-0313 | ISO 8879 SGML | Memento, Naggum Software | | DIS 10744 HyTime | terrigena. Boks 1570, Vika | \<erik@naggum.no> | JTC 1/SC 18/WG 8 | Memento, 0118 OSLO, NORWAY | \<enag@ifi.uio.no> | SGML UG SIGhyper | vita brevis. </message> <message id="<23067C@erik.naggum.no>" date="2910566396"> Newsgroups: comp.text.sgml Date: 26 Mar 1992 02:39:56 UT From: Erik Naggum \<erik@naggum.no> Reply-To: Erik Naggum \<enag@ifi.uio.no> Organization: Naggum Software, Oslo, Norway Message-ID: <23067C@erik.naggum.no> Subject: List of files at SGML FTP sites The following is a comprehensive listing of all the files that I have found on sgml1.ex.ac.uk, mailer.cc.fsu.edu and ftp.ifi.uio.no tonight. If you don't find this useful, and think I should not post more of them, please inform me privately. For those who cannot use FTP, I'm always willing to mail out files from ftp.ifi.uio.no. Send mail to \<SIGhyper-request@ifi.uio.no>. I intend to keep abreast of the files available on the other sites, but don't have time to sort through what's what where right now. Maybe next time, if this is well received. Here goes. Ooops, this got too big. I have deleted the long listing of the article archives for comp.text.sgml, and retained only a list of message-ids. If you have any other articles from comp.text.sgml, please mail their message-ids to me (not the whole message, please). Regards, \</Erik> -------------------- FTP.IFI.UIO.NO -------------------- /pub/SGML: drwxr-sr-x 2 enag enag 1024 Jan 14 17:10 CALS drwxr-sr-x 2 enag enag 512 Feb 13 01:49 DTD drwxr-sr-x 2 enag enag 512 Jan 14 17:44 ENTITIES -rw-r--r-- 1 enag enag 18219 Dec 15 12:03 FAQ.0.0 drwxr-sr-x 2 enag enag 1536 Jan 14 17:09 TEI -rw-r--r-- 1 enag enag 167974 Jan 20 22:50 bibliography drwxr-sr-x 4 enag enag 512 Feb 2 03:42 comp.text.sgml -rw-r--r-- 1 enag enag 231689 Feb 9 22:34 davenport.dgdas.1.ps.Z /pub/SGML/CALS: -rw-r--r-- 1 enag enag 130669 Dec 8 06:01 1840a.txt -rw-r--r-- 1 enag enag 132615 Dec 8 02:54 28000a.txt -rw-r--r-- 1 enag enag 56985 Dec 8 02:57 28001.app-a10-.txt -rw-r--r-- 1 enag enag 61537 Dec 8 02:57 28001.app-a50.txt -rw-r--r-- 1 enag enag 7024 Dec 8 02:57 28001.app-a60.txt -rw-r--r-- 1 enag enag 132626 Dec 8 02:58 28001.app-a70a.txt -rw-r--r-- 1 enag enag 133972 Dec 8 02:58 28001.app-a70b.txt -rw-r--r-- 1 enag enag 132505 Dec 8 02:58 28001.app-a70c.txt -rw-r--r-- 1 enag enag 32483 Dec 8 02:59 28001.app-a80.txt -rw-r--r-- 1 enag enag 204519 Dec 8 02:59 28001.app-b10-.txt -rw-r--r-- 1 enag enag 148244 Dec 8 03:00 28001.app-b50.txt -rw-r--r-- 1 enag enag 3604 Dec 8 03:00 28001.app-b60.txt -rw-r--r-- 1 enag enag 65704 Dec 8 03:01 28001.app-b70.txt -rw-r--r-- 1 enag enag 93757 Dec 8 03:01 28001.app-b80.txt -rw-r--r-- 1 enag enag 11461 Dec 8 03:01 28001.app-b90.txt -rw-r--r-- 1 enag enag 170002 Dec 8 03:02 28001.app-c10-.txt -rw-r--r-- 1 enag enag 77850 Dec 8 03:02 28001.app-d10-.txt -rw-r--r-- 1 enag enag 6437 Dec 8 03:02 28001.app-d40.txt -rw-r--r-- 1 enag enag 76033 Dec 8 03:02 28001.app-d50.txt -rw-r--r-- 1 enag enag 57940 Jan 26 23:16 28001a.txt -rw-r--r-- 1 enag enag 147737 Dec 8 02:56 28002a.txt -rw-r--r-- 1 enag enag 112592 Dec 8 02:54 28003a.txt -rw-r--r-- 1 enag enag 38400 Dec 8 03:09 38784-v2.pid -rw-r--r-- 1 enag enag 101197 Dec 8 03:11 59a.app-a.txt -rw-r--r-- 1 enag enag 181799 Dec 8 03:11 59a.app-b.txt -rw-r--r-- 1 enag enag 133097 Dec 8 03:12 59a.app-c.txt -rw-r--r-- 1 enag enag 97956 Dec 8 03:12 59a.app-d.txt -rw-r--r-- 1 enag enag 44395 Dec 8 03:12 59a.app-e.txt -rw-r--r-- 1 enag enag 144063 Dec 8 03:13 59a.hdbk-59a.txt -rw-r--r-- 1 enag enag 21379 Dec 8 03:09 outspec.pid -rw-r--r-- 1 enag enag 5605 Dec 8 03:10 read.me -rw-r--r-- 1 enag enag 75905 Dec 8 03:09 template.fos -rw-r--r-- 1 enag enag 33531 Dec 8 03:09 template.pid /pub/SGML/DTD: -rw-r--r-- 1 enag enag 30843 Feb 12 19:36 com8879 -rw-r--r-- 1 enag enag 9767 Jan 30 21:46 general -rw-r--r-- 1 enag enag 12287 Jan 30 22:03 general.ex -rw-r--r-- 1 enag enag 10962 Feb 12 23:07 mod-general -rw-r--r-- 1 enag enag 13490 Jan 30 22:04 mod-general.ex /pub/SGML/ENTITIES: -rw-r--r-- 1 enag enag 4310 Jan 13 21:23 ISOamsa -rw-r--r-- 1 enag enag 3262 Jan 13 21:24 ISOamsb -rw-r--r-- 1 enag enag 1080 Jan 13 21:24 ISOamsc -rw-r--r-- 1 enag enag 4474 Jan 13 21:22 ISOamsn -rw-r--r-- 1 enag enag 1593 Jan 13 21:19 ISOamso -rw-r--r-- 1 enag enag 6036 Jan 13 21:26 ISOamsr -rw-r--r-- 1 enag enag 3379 Jan 13 21:21 ISObox -rw-r--r-- 1 enag enag 4324 Jan 13 21:20 ISOcyr1 -rw-r--r-- 1 enag enag 1938 Jan 13 21:18 ISOcyr2 -rw-r--r-- 1 enag enag 1071 Jan 13 21:17 ISOdia -rw-r--r-- 1 enag enag 3204 Jan 13 21:22 ISOgrk1 -rw-r--r-- 1 enag enag 1755 Jan 13 21:16 ISOgrk2 -rw-r--r-- 1 enag enag 2885 Jan 13 21:17 ISOgrk3 -rw-r--r-- 1 enag enag 2983 Jan 13 21:21 ISOgrk4 -rw-r--r-- 1 enag enag 4296 Jan 14 17:44 ISOlat1 -rw-r--r-- 1 enag enag 7389 Jan 13 21:26 ISOlat2 -rw-r--r-- 1 enag enag 4809 Jan 13 21:15 ISOnum -rw-r--r-- 1 enag enag 5538 Jan 13 21:26 ISOpub -rw-r--r-- 1 enag enag 4297 Jan 13 21:15 ISOtech /pub/SGML/TEI: -rw-r--r-- 1 enag enag 20661 Jun 12 1991 AI1W3.MEMO -rw-r--r-- 1 enag enag 32886 Jun 12 1991 AI3W4.MEMO -rw-r--r-- 1 enag enag 44067 Jun 12 1991 AI3W5.MEMO -rw-r--r-- 1 enag enag 30081 Oct 10 08:50 EDP1.MEMO -rw-r--r-- 1 enag enag 7449 Jun 12 1991 EDP3.MEMO -rw-r--r-- 1 enag enag 7899 Jan 2 01:36 FILELIST -rw-r--r-- 1 enag enag 34878 Jun 10 1991 LPUNCH.MEMO -rw-r--r-- 1 enag enag 16036 Jun 12 1991 MLW13.MEMO -rw-r--r-- 1 enag enag 4803 Jun 11 1991 PCP1.MEMO -rw-r--r-- 1 enag enag 1638 Jun 12 1991 TEI-L.LOG8903 -rw-r--r-- 1 enag enag 1463 Jun 12 1991 TEI-L.LOG8904 -rw-r--r-- 1 enag enag 11732 Jun 12 1991 TEI-L.LOG8905 -rw-r--r-- 1 enag enag 4071 Jun 12 1991 TEI-L.LOG8906 -rw-r--r-- 1 enag enag 17478 Jun 12 1991 TEI-L.LOG8907 -rw-r--r-- 1 enag enag 21971 Jun 12 1991 TEI-L.LOG8908 -rw-r--r-- 1 enag enag 47764 Jun 12 1991 TEI-L.LOG8909 -rw-r--r-- 1 enag enag 140247 Jun 12 1991 TEI-L.LOG8910 -rw-r--r-- 1 enag enag 36411 Jun 12 1991 TEI-L.LOG8911 -rw-r--r-- 1 enag enag 2844 Jun 12 1991 TEI-L.LOG8912 -rw-r--r-- 1 enag enag 5295 Jun 12 1991 TEI-L.LOG9001 -rw-r--r-- 1 enag enag 89353 Jun 12 1991 TEI-L.LOG9002 -rw-r--r-- 1 enag enag 5028 Jun 12 1991 TEI-L.LOG9003 -rw-r--r-- 1 enag enag 5009 Jun 12 1991 TEI-L.LOG9004 -rw-r--r-- 1 enag enag 11027 Jun 12 1991 TEI-L.LOG9006 -rw-r--r-- 1 enag enag 33195 Jun 12 1991 TEI-L.LOG9007 -rw-r--r-- 1 enag enag 79821 Jun 12 1991 TEI-L.LOG9008 -rw-r--r-- 1 enag enag 29509 Jun 12 1991 TEI-L.LOG9009 -rw-r--r-- 1 enag enag 318203 Jun 12 1991 TEI-L.LOG9010 -rw-r--r-- 1 enag enag 175993 Jun 12 1991 TEI-L.LOG9011 -rw-r--r-- 1 enag enag 51444 Jun 12 1991 TEI-L.LOG9012 -rw-r--r-- 1 enag enag 88118 Jun 12 1991 TEI-L.LOG9101 -rw-r--r-- 1 enag enag 175226 Jun 12 1991 TEI-L.LOG9102 -rw-r--r-- 1 enag enag 32900 Jun 12 1991 TEI-L.LOG9103 -rw-r--r-- 1 enag enag 47152 Jun 12 1991 TEI-L.LOG9104 -rw-r--r-- 1 enag enag 39376 Jun 12 1991 TEI-L.LOG9105 -rw-r--r-- 1 enag enag 42665 Oct 10 06:51 TEI-L.LOG9106 -rw-r--r-- 1 enag enag 34447 Oct 10 06:52 TEI-L.LOG9107 -rw-r--r-- 1 enag enag 93542 Oct 10 06:52 TEI-L.LOG9108 -rw-r--r-- 1 enag enag 97729 Oct 10 06:55 TEI-L.LOG9109 -rw-r--r-- 1 enag enag 31294 Jan 2 01:34 TEI-L.LOG9110 -rw-r--r-- 1 enag enag 122464 Jan 2 01:35 TEI-L.LOG9111 -rw-r--r-- 1 enag enag 77703 Jan 2 01:35 TEI-L.LOG9112 -rw-r--r-- 1 enag enag 8195 Jun 11 1991 TEI1.DTD -rw-r--r-- 1 enag enag 1602 Jun 11 1991 TEIBACK1.DTD -rw-r--r-- 1 enag enag 4217 Jun 11 1991 TEIBASE1.DTD -rw-r--r-- 1 enag enag 7494 Jun 11 1991 TEICRYS1.DTD -rw-r--r-- 1 enag enag 6005 Jun 11 1991 TEIDRAM1.DTD -rw-r--r-- 1 enag enag 3287 Jun 11 1991 TEIFRON1.DTD -rw-r--r-- 1 enag enag 14861 Jun 11 1991 TEIHDR1.DTD -rw-r--r-- 1 enag enag 13087 Jun 11 1991 TEIJ10.MEMO -rw-r--r-- 1 enag enag 8054 Jun 11 1991 TEIJ6.MEMO -rw-r--r-- 1 enag enag 4819 Jun 11 1991 TEILING1.DTD -rw-r--r-- 1 enag enag 6856 Jun 11 1991 TEILOW1.DTD -rw-r--r-- 1 enag enag 13294 Jun 11 1991 TEIP1.ERRATA -rw-r--r-- 1 enag enag 2605 Jun 11 1991 TEIREND1.DTD -rw-r--r-- 1 enag enag 3191 Jun 11 1991 TEITC1.DTD -rw-r--r-- 1 enag enag 2828 Jun 11 1991 TEIWSD1.DTD -rw-r--r-- 1 enag enag 26277 Jun 10 1991 iso8859.critique /pub/SGML/comp.text.sgml: drwxr-sr-x 2 enag enag 17408 Mar 25 06:01 by.date drwxr-sr-x 2 enag enag 27136 Mar 25 06:01 by.msgid /pub/SGML/comp.text.sgml/by.date: [Not included in total. This is simply a link to the files in by.msgid, with filenames like "1991-03-20_11:42:50" for the date and time in GMT.] /pub/SGML/comp.text.sgml/by.msgid: <"14-Feb-92.12:38:53"..Wilson_D_G_A.marl@rx.Xerox.com> <+--ISBN_82-7640-006--TEXT_Article_17--EN@naggum.no> <+--ISBN_82-7640-006--TEXT_Article_18--EN@naggum.no> <01050002.v3bv5o@petnet.in-berlin.de> <01050002.vy3t2r@petnet.in-berlin.de> <09697A@erik.naggum.no> <09697C@erik.naggum.no> <09697D@erik.naggum.no> <09699A@erik.naggum.no> <0dmC3Xu00hMg4iPJ8h@cs.cmu.edu> <1020@ictser.UUCP> <10418@cactus.org> <111@grappa.serc.nl> <11222@nfs4.rl.ac.uk> <112@grappa.serc.nl> <114490002@hpcvlx.cv.hp.com.> <11587@neil.rl.ac.uk> <1200.2986c9e1@hermes.dlogics.com> <1201.2986cc8c@hermes.dlogics.com> <121@cipc1.DaytonOH.NCR.COM> <1262@qusunl.queensu.CA> <1289@bcstec.boeing.com> <13333@rayssd.ssd.ray.com> <13334@rayssd.ssd.ray.com> <1588@bcstec.boeing.com> <1619@bcstec.boeing.com> <16253.9106241826@olympus.cs.hull.ac.uk> <16565.9106172237@olympus.cs.hull.ac.uk> <1705@bcstec.boeing.com> <1706@bcstec.boeing.com> <1707@bcstec.boeing.com> <1853@creatures.cs.vt.edu> <1877@targon.UUCP> <1884@creatures.cs.vt.edu> <1900@bcstec.boeing.com> <1918@bcstec.boeing.com> <1940@creatures.cs.vt.edu> <1979@irit.irit.fr> <1991-128-78110@uunic.uu.no> <1991-147-82129@naggum.no> <1991Apr12.153932.19465@convex.com> <1991Apr12.183430.5896@sq.com> <1991Apr13.150936.5970@cc.helsinki.fi> <1991Apr8.165150.10496@sq.sq.com> <1991Apr9.143302.25899@sq.sq.com> <1991Aug1.142641.17369@HQ.Ileaf.COM> <1991Aug12.152452.23215@maytag.waterloo.edu> <1991Aug15.155940.65161@pttrnl.nl> <1991Aug19.134340.16108@hal.com> <1991Aug2.195844.600@hal.com> <1991Aug2.205914.18240@walter.bellcore.com> <1991Aug4.131837.22558@nntp.hut.fi> <1991Aug4.172309.1345@vax.oxford.ac.uk> <1991Aug4.220653.8243@ousrvr.oulu.fi> <1991Aug5.154247.20986@mnemosyne.cs.du.edu> <1991Aug6.103526.1@ilp.mit.edu> <1991Aug8.132002.28352@hal.com> <1991Aug8.132055.28409@hal.com> <1991Dec04.152951.13391@ghost.dsi.unimi.it> <1991Dec10.094519.24329@sun1.ruf.uni-freiburg.de> <1991Dec11.144044.1199@wam.umd.edu> <1991Dec16.180507.12369@csi.uottawa.ca> <1991Dec17.230029.21288@sq.sq.com> <1991Dec21.015801.23830@convex.com> <1991Dec21.195207.19785@cbnewsi.cb.att.com> <1991Dec22.220346.12365@msen.com> <1991Dec3.065623.4104@lth.se> <1991Dec3.174029.7057@csv.viccol.edu.au> <1991Dec30.145322.24727@ghost.dsi.unimi.it> <1991Dec31.154938.28280@cherokee.uswest.com> <1991Dec4.191700.26848@hal.com> <1991Jul10.141006.13655@hal.com> <1991Jul18.200608.4595@sq.com> <1991Jul23.225440.19426@iscnvx.lmsc.lockheed.com> <1991Jul8.180824.18462@hal.com> <1991Jul8.213957.23957@cs.rochester.edu> <1991Jul8.225934.10392@bohra.cpg.oz.au> <1991Jun12.131914.19072@hal.com> <1991Jun13.135420.29128@hal.com> <1991Jun17.215959.29937@hal.com> <1991Jun18.133046.8636@sq.com> <1991Jun21.114855.7980@swift.cs.tcd.ie> <1991Jun24.120809.7984@swift.cs.tcd.ie> <1991Jun26.201441.29054@hal.com> <1991Jun27.144331.17689@iscnvx.uucp> <1991Jun29.024208.24427@sq.com> <1991Jun6.164813.18827@fwi.uva.nl> <1991May20.024409.21904@isc.rit.edu> <1991May20.203943.27987@noose.ecn.purdue.edu> <1991May24.183946.11866@noose.ecn.purdue.edu> <1991Nov1.151851.19876@aber.ac.uk> <1991Nov1.155456.23229@aber.ac.uk> <1991Nov11.095258.517@gnv.ifas.ufl.edu> <1991Nov12.194658.14030bosak@netcom.COM> <1991Nov16.204023.14683@am.sublink.org> <1991Nov25.105921.19096@luotsi.uku.fi> <1991Nov27.085250.4083@lth.se> <1991Nov30.183550.7748bosak@netcom.COM> <1991Nov7.175807.13624@aber.ac.uk> <1991Oct1.132826.14207@turing.ac.uk> <1991Oct1.152703.10529@aber.ac.uk> <1991Oct1.205408.8123@sq.sq.com> <1991Oct11.144656.14990@aber.ac.uk> <1991Oct13.071556.21203@gpu.utcs.utoronto.ca> <1991Oct16.071959.28458@monu6.cc.monash.edu.au> <1991Oct16.195543.19369@sco.COM> <1991Oct17.195404.21958@convex.com> <1991Oct17.224213.11641@hal.com> <1991Oct18.163713.11775@aber.ac.uk> <1991Oct2.114313.4261@ulrik.uio.no> <1991Oct2.173806.2124@hal.com> <1991Oct2.194101.10974@sq.sq.com> <1991Oct21.235920.1114@monu6.cc.monash.edu.au> <1991Oct27.024823.7461@cbnewsi.cb.att.com> <1991Oct29.182801.18640@menudo.uh.edu> <1991Oct3.004524.13366@cbnewsi.cb.att.com> <1991Oct3.175546.8529@sics.se> <1991Oct31.174853.8251@zip.eecs.umich.edu> <1991Oct4.133233.29044@ulrik.uio.no> <1991Oct4.145648.26478@meaddata.com> <1991Oct4.200305.29520@meaddata.com> <1991Oct5.131628.12995@cbnewsm.att.com> <1991Oct7.112225.16997@turing.ac.uk> <1991Oct7.130435.48310@ccvax.ucd.ie> <1991Oct8.145236.25492@ecsvax.uncecs.edu> <1991Sep10.222629.19904@watdragon.waterloo.edu> <1991Sep11.115209.1781@vax.oxford.ac.uk> <1991Sep11.164807.9983@chpc.utexas.edu> <1991Sep13.135301.9607@HQ.Ileaf.COM> <1991Sep13.143504.398@sparrms.ists.ca> <1991Sep13.204528.22158@sq.sq.com> <1991Sep14.171344.1132@HQ.Ileaf.COM> <1991Sep15.001713.11711@usenet@CS.ORST.EDU> <1991Sep17.150512.5903@apollo.hp.com> <1991Sep17.181747.12652@cis.ohio-state.edu> <1991Sep17.191327.1865@vax.oxford.ac.uk> <1991Sep18.122938.18906@cbnewsi.cb.att.com> <1991Sep18.233839.8940@cbnewsi.cb.att.com> <1991Sep19.005921.19747@usenet@CS.ORST.EDU> <1991Sep19.153641.3286@cbnewsl.cb.att.com> <1991Sep20.014955.19124@usenet@CS.ORST.EDU> <1991Sep20.030118.17356@cbnewsi.cb.att.com> <1991Sep20.140323.48295@ccvax.ucd.ie> <1991Sep20.213103.8345@HQ.Ileaf.COM> <1991Sep22.062816.18582bosak@netcom.COM> <1991Sep22.063046.18634bosak@netcom.COM> <1991Sep23.134305.27949@turing.ac.uk> <1991Sep24.024653.22131@usenet@CS.ORST.EDU> <1991Sep24.035534.23218@usenet@CS.ORST.EDU> <1991Sep24.233410.26483@meaddata.com> <1991Sep25.050849.3013bosak@netcom.COM> <1991Sep26.041259.20449@usenet@CS.ORST.EDU> <1991Sep29.211224.6800@cbnewsi.cb.att.com> <1991Sep30.083442.20019@nuscc.nus.sg> <1991Sep5.200832.20910@searchtech.com> <1991Sep6.013810.757@cbnewsi.cb.att.com> <199203172128.AA00779@support.avalanche.com> <1992Feb10.091457.22735@rdg.dec.com> <1992Feb10.091832.22913@rdg.dec.com> <1992Feb10.174214.4060@watmath.waterloo.edu> <1992Feb11.083659.2623@rdg.dec.com> <1992Feb11.173436.18930@uni2b.unige.ch> <1992Feb12.095012.28649@rdg.dec.com> <1992Feb14.205650.26070@epas.toronto.edu> <1992Feb17.050813.7778@ultb.isc.rit.edu> <1992Feb18.111438.7164@owf.ch> <1992Feb20.181955.9874@epas.toronto.edu> <1992Feb3.155842.10983@infonode.ingr.com> <1992Feb5.030423.15580@qucis.queensu.ca> <1992Feb6.030746.22262@Csli.Stanford.EDU> <1992Feb8.025728.12805@Csli.Stanford.EDU> <1992Jan06.172144.23938@convex.com> <1992Jan10.104050.4997@sun1.ruf.uni-freiburg.de> <1992Jan10.191101.621@rayssd.ssd.ray.com> <1992Jan13.093256.27192@nuscc.nus.sg> <1992Jan13.185802.11754bosak@netcom.COM> <1992Jan14.013441.2263@bohra.cpg.oz.au> <1992Jan16.224217.28008@cherokee.uswest.com> <1992Jan18.222001.4230@ulowell.ulowell.edu> <1992Jan20.202328.12178@rayssd.ssd.ray.com> <1992Jan21.101535.15896@sun1.ruf.uni-freiburg.de> <1992Jan21.104106.16137@sun1.ruf.uni-freiburg.de> <1992Jan21.175726.20018@convex.com> <1992Jan22.015052.7116@csv.viccol.edu.au> <1992Jan22.170351.11455@sq.sq.com> <1992Jan22.212855.14273@epas.toronto.edu> <1992Jan22.223048.8852@convex.com> <1992Jan23.031524.13880@visix.com> <1992Jan23.141325.5870@rayssd.ssd.ray.com> <1992Jan23.151324.6628@rayssd.ssd.ray.com> <1992Jan23.160730.21839@watserv1.waterloo.edu> <1992Jan24.021854.25189@ulowell.ulowell.edu> <1992Jan26.155817.23284bosak@netcom.COM> <1992Jan28.102007.15250@sun1.ruf.uni-freiburg.de> <1992Jan28.132338.6757@epas.toronto.edu> <1992Jan29.142335.798@epas.toronto.edu> <1992Jan3.205853.16249@fwi.uva.nl> <1992Jan30.122128.28919@epas.toronto.edu> <1992Jan30.140834.4724@infonode.ingr.com> <1992Jan30.150707.8838@cis.ohio-state.edu> <1992Jan30.183901.5799@rayssd.ssd.ray.com> <1992Jan31.011128.14225@cs.cornell.edu> <1992Jan31.162117.20745@sq.sq.com> <1992Jan31.174711.3713@HQ.Ileaf.COM> <1992Jan31.220607.15084@infonode.ingr.com> <1992Jan4.235049.25375@cbnewsi.cb.att.com> <1992Jan6.194814.6955@watserv1.waterloo.edu> <1992Jan7.193415.20151@csn.org> <1992Jan8.154429.23502@cherokee.uswest.com> <1992Jan8.154905.23563@cherokee.uswest.com> <1992Jan8.183814.2661@sqwest.wimsey.bc.ca> <1992Jan8.204710.19304@tfic.bc.ca> <1992Jan9.032512.7196@csn.org> <1992Jan9.033713.7762@csn.org> <1992Jan9.035247.9966@csn.org> <1992Jan9.160933.9091@cherokee.uswest.com> <1992Jan9.161249.9174@cherokee.uswest.com> <1992Mar10.174735.4897@vax.oxford.ac.uk> <1992Mar12.155828.16971@apollo.hp.com> <1992Mar16.071317.29441@nuscc.nus.sg> <1992Mar16.152312.20696@epas.toronto.edu> <1992Mar19.141613.946@gnv.ifas.ufl.edu> <1992Mar19.215608.13245@qucis.queensu.ca> <1992Mar19.215847.13335@qucis.queensu.ca> <1992Mar19.231100.8990@exu.ericsson.se> <1992Mar20.202712.22342@infonode.ingr.com> <1992Mar21.060244.5301@cs.ucla.edu> <1992Mar23.152245.2812@wam.umd.edu> <1992Mar24.034943.21594@msen.com> <1992Mar24.073931.16933@bohra.cpg.oz.au> <1992Mar4.065157.22177@cs.brown.edu> <1992Mar9.052559.11273@syacus.acus.oz.au> <20452@arctic.nprdc.navy.mil> <20454@arctic.nprdc.navy.mil> <2056@bcstec.boeing.com> <2078@exua.exeter.ac.uk> <2111@exua.exeter.ac.uk> <21121@gremlin.nrtc.northrop.com> <22013@alice.att.com> <22026@alice.att.com> <2206@babcock.cerc.wvu.wvnet.edu> <22070@alice.att.com> <22071@alice.att.com> <22122@alice.att.com> <22177@alice.att.com> <22745A1@erik.naggum.no> <22745A2@erik.naggum.no> <22747A@erik.naggum.no> <22751C@erik.naggum.no> <22751D@erik.naggum.no> <22752A@erik.naggum.no> <22753A@erik.naggum.no> <22753B1@erik.naggum.no> <22753B@erik.naggum.no> <22753C@erik.naggum.no> <22753D@erik.naggum.no> <22753E@erik.naggum.no> <22753F@erik.naggum.no> <22754A@erik.naggum.no> <22756B@erik.naggum.no> <22757B@erik.naggum.no> <22762A@erik.naggum.no> <22764A@erik.naggum.no> <22765B@erik.naggum.no> <22765C@erik.naggum.no> <22765D@erik.naggum.no> <22765E@erik.naggum.no> <22765F@erik.naggum.no> <22766A@erik.naggum.no> <22766B@erik.naggum.no> <22766C@erik.naggum.no> <22767C@erik.naggum.no> <22770A@erik.naggum.no> <22773A@erik.naggum.no> <22774A@erik.naggum.no> <22774B@erik.naggum.no> <22777A@erik.naggum.no> <22777C@erik.naggum.no> <22777F@erik.naggum.no> <23003B@erik.naggum.no> <23004B@erik.naggum.no> <23006B@erik.naggum.no> <23006D@erik.naggum.no> <23012A@erik.naggum.no> <23012B@erik.naggum.no> <23013A@erik.naggum.no> <23013B@erik.naggum.no> <23015A@erik.naggum.no> <23021A@erik.naggum.no> <23024A@erik.naggum.no> <23055B@erik.naggum.no> <23057C@erik.naggum.no> <23169@paperboy.OSF.ORG> <25030@arctic.nprdc.navy.mil> <2512@aber-cs.UUCP> <25273@gremlin.nrtc.northrop.com> <261@xyvi.UUCP> <28272@darkstar.ucsc.edu> <2pbpr_#@rpi.edu> <3081@inca.comlab.ox.ac.uk> <32172@uflorida.cis.ufl.EDU> <32610@gremlin.nrtc.northrop.com> <34403@gremlin.nrtc.northrop.com> <34463@gremlin.nrtc.northrop.com> <348@salt.bellcore.com> <34B1DB1w164w@knex.Gwinnett.COM> <35793@gremlin.nrtc.northrop.com> <36276@gremlin.nrtc.northrop.com> <3635@lulea.telesoft.se> <366@salt.bellcore.com> <37886@mimsy.umd.edu> <393@arbortext.UUCP> <394@arbortext.UUCP> <40230001@aspen.IAG.HP.COM> <418@salt.bellcore.com> <435@sunatb.UUCP> <442@salt.bellcore.com> <446@txsil.lonestar.org> <448@salt.bellcore.com> <451@txsil.lonestar.org> <4525@loria.crin.fr> <461@news.duke.edu> <464@salt.bellcore.com> <470@txsil.lonestar.org> <471@txsil.lonestar.org> <489@salt.bellcore.com> <491@salt.bellcore.com> <4923@gmdzi.gmd.de> <4coE8_k000001OAkYT@andrew.cmu.edu> <5050@gmdzi.gmd.de> <5106@gmdzi.gmd.de> <517@news.duke.edu> <518@devnull.mpd.tandem.com> <5318@gmdzi.gmd.de> <5335@darmstadt.gmd.de> <5786@gmdzi.gmd.de> <5sZPcB1w164w@knex.Gwinnett.COM> <600@txsil.lonestar.org> <6012@uqcspe.cs.uq.oz.au> <605@txsil.lonestar.org> <6071@uqcspe.cs.uq.oz.au> <607@txsil.lonestar.org> <609@txsil.lonestar.org> <610@txsil.lonestar.org> <611@txsil.lonestar.org> <612@txsil.lonestar.org> <613@txsil.lonestar.org> <6154@gmdzi.gmd.de> <6175@eastapps.East.Sun.COM> <6271@eastapps.East.Sun.COM> <631@salt.bellcore.com> <646@salt.bellcore.com> <6692@cernvax.cern.ch> <6733@gmdzi.gmd.de> <6803@oasys.dt.navy.mil> <6850@gmdzi.gmd.de> <6872@gmdzi.gmd.de> <69376@bcsaic.UUCP> <694@salt.bellcore.com> <7031@gmdzi.gmd.de> <7085@hemuli.tik.vtt.fi> <7107@hemuli.tik.vtt.fi> <7485@eastapps.East.Sun.COM> <784@ajpo.sei.cmu.edu> <8156@eastapps.East.Sun.COM> <817@AJPO.sei.cmu.edu> <82-7640-006-X:0003@naggum.no> <82-7640-006-X:0004@naggum.no> <82-7640-006-X:0005@naggum.no> <82-7640-006-X:0006@naggum.no> <82-7640-006-X:0008@naggum.no> <82-7640-006-X:0009@naggum.no> <82-7640-006-X:0010@naggum.no> <82-7640-006-X:0014@naggum.no> <82-7640-006-X:0015@gyda.ifi.uio.no> <82-7640-006-X:0016@gyda.ifi.uio.no> <82-7640-040-9671-1@naggum.no> <850@tivoli.UUCP> <852028e.695924063@aucs> <864@salt.bellcore.com> <875@rufus.UUCP> <878@rufus.UUCP> <881@salt.bellcore.com> <89928@brunix.UUCP> <9105161335.AA22164@kirk> <9106172304.AA05241@ucbvax.Berkeley.EDU> <9107121624.AA25980@cmrp.cmr.uucp> <9107192225.AA01249@cmrp.cmr.uucp> <9108051819.AA11895@cmrp.cmr.uucp> <9109180338.AA01875@mingus.tti> <9109271525.AA00904@mingus.tti> <9109281841.AA00229@mingus.tti> <9109300029.AA00687@mingus.tti> <9110030116.AA01936@mingus.tti> <9110030122.AA01980@mingus.tti> <9110081309.AA00987@ucbvax.Berkeley.EDU> <9110081424.AA00167@mingus.tti> <9110151809.AA26697@ucbvax.Berkeley.EDU> <9110171854.AA02772@ucbvax.Berkeley.EDU> <9110291728.AA00925@mingus.tti> <9111020157.AA03637@mingus.tti> <9111131439.AA18321@ucbvax.Berkeley.EDU> <9112231102.AA16114@ucbvax.Berkeley.EDU> <91185.181304GONTER@awiwuw11.wu-wien.ac.at> <91354.111948U35395@uicvm.uic.edu> <9201021017.AA00599@ucbvax.Berkeley.EDU> <9201021027.AA01337@ucbvax.Berkeley.EDU> <9201032128.AA15044@ucbvax.Berkeley.EDU> <9201041529.AA08770@mingus.tti> <9201061927.AA07320@ucbvax.Berkeley.EDU> <9201071440.AA15409@mingus.tti> <9201071518.AA15567@mingus.tti> <9201072033.AA05749@ucbvax.Berkeley.EDU> <9201072322.AA19291@mingus.tti> <9201081610.AA06139@ucbvax.Berkeley.EDU> <9201091837.AA12197@ucbvax.Berkeley.EDU> <9201101804.AA15067@ucbvax.Berkeley.EDU> <9201152027.AA13880@mingus.tti> <9201161403.AA10418@ucbvax.Berkeley.EDU> <9201161601.AA15477@mingus.tti> <9201161625.AA15523@mingus.tti> <9201171629.AA06348@ucbvax.Berkeley.EDU> <9201211806.AA04522@ucbvax.Berkeley.EDU> <9201212352.AA00572@mingus.tti> <9201242117.AA03132@ucbvax.Berkeley.EDU> <9201301415.AA05365@ucbvax.Berkeley.EDU> <92016.171448U35395@uicvm.uic.edu> <9202092045.AA26782@mingus.tti> <9202112036.AA17283@ucbvax.Berkeley.EDU> <9202151409.AA26548@ucbvax.Berkeley.EDU> <9202181341.AA01679@ucbvax.Berkeley.EDU> <9202282324.AA24222@ucbvax.Berkeley.EDU> <9203062208.AA28014@ucbvax.Berkeley.EDU> <9203201330.AA17829@ucbvax.Berkeley.EDU> <92071.222932U35395@uicvm.uic.edu> <92984@bu.edu> <932@bcstec.boeing.com> <9359@goanna.cs.rmit.oz.au> <9576@fs3.cam.nist.gov> <963@baby.and.nl> <9686.002@erik.naggum.no> <9687A1@erik.naggum.no> <9688A1@erik.naggum.no> <9688B1@erik.naggum.no> <9692A1@erik.naggum.no> \<ABJ.91Jul30141436@mina6.ida.liu.se> \<APS.91Jul29184221@kaarne.cs.tut.fi> \<BEAUDOIN.92Mar17145158@felix.ireq-robot.hydro.qc.ca> \<BJJt3q.LzB@world.std.com> \<BRAHM.92Jan17145101@mpii02019.world> \<CABO.91Aug16183903@kraftbus.cs.tu-berlin.de> \<CABO.91Dec20145354@kraftbus.cs.tu-berlin.de> \<CABO.91Jun27172641@kraftbus.cs.tu-berlin.de> \<CABO.91Sep23144056@kraftbus.cs.tu-berlin.de> \<CABO.92Feb20185904@kraftbus.cs.tu-berlin.de> \<CABO.92Feb20191252@kraftbus.cs.tu-berlin.de> \<DAN.91Dec30165047@dan.watson.ibm.com> \<DAN.91Dec30172214@dan.watson.ibm.com> \<DGD.91Aug2131032@bucsd.bu.edu> \<DGD.91Dec9162210@cs.bu.edu> \<DGD.91Sep15154115@cs.bu.edu> \<DGD.91Sep19150740@cs.bu.edu> \<DGD.91Sep21154129@cs.bu.edu> \<DML.91Jun24100620@acoustat.esl.com> \<EMV.91Aug21171602@seuss.aa.ox.com> \<EMV.91Dec17133041@shelley.aa.ox.com> \<EMV.91Dec26165124@shelley.aa.ox.com> \<EMV.91Dec30184535@shelley.aa.ox.com> \<EMV.91Dec4151558@shelley.aa.ox.com> \<EMV.91Jun21173725@bronte.aa.ox.com> \<EMV.91Jun22002232@bronte.aa.ox.com> \<EMV.91Jun23144034@bronte.aa.ox.com> \<EMV.91Jun24204932@bronte.aa.ox.com> \<EMV.91Jun28012346@bronte.aa.ox.com> \<EMV.91Oct11130853@goose.aa.ox.com> \<EMV.91Oct11171720@goose.aa.ox.com> \<EMV.91Oct16110551@shelley.aa.ox.com> \<ENAG.91Apr12065555@maud.ifi.uio.no> \<ENAG.91Apr3141917@holmenkollen.ifi.uio.no> \<ENAG.91Apr4173517@holmenkollen.ifi.uio.no> \<ENAG.91Apr5182519@holmenkollen.ifi.uio.no> \<ENAG.91Apr9232530@maud.ifi.uio.no> \<ENAG.91Aug13160300@gyda.ifi.uio.no> \<ENAG.91Aug13161500@gyda.ifi.uio.no> \<ENAG.91Aug17184327@gyda.ifi.uio.no> \<ENAG.91Aug22234858@gyda.ifi.uio.no> \<ENAG.91Dec11085204@gyda.ifi.uio.no> \<ENAG.91Dec15130001@gyda.ifi.uio.no> \<ENAG.91Jul10011555@gyda.ifi.uio.no> \<ENAG.91Jul16233003@gyda.ifi.uio.no> \<ENAG.91Jul19182602@gyda.ifi.uio.no> \<ENAG.91Jul2205334@gyda.ifi.uio.no> \<ENAG.91Jul2211610@gyda.ifi.uio.no> \<ENAG.91Jul4042139@gyda.ifi.uio.no> \<ENAG.91Jul8220436@gyda.ifi.uio.no> \<ENAG.91Jun13022623@gyda.ifi.uio.no> \<ENAG.91Jun14163052@gyda.ifi.uio.no> \<ENAG.91Jun25011614@gyda.ifi.uio.no> \<ENAG.91Jun25013811@gyda.ifi.uio.no> \<ENAG.91Jun29151127@gyda.ifi.uio.no> \<ENAG.91Jun9020802@gyda.ifi.uio.no> \<ENAG.91Jun9024955@gyda.ifi.uio.no> \<ENAG.91May14032548@maud.ifi.uio.no> \<ENAG.91May23192753@gyda.ifi.uio.no> \<ENAG.91May25164847@gyda.ifi.uio.no> \<ENAG.91May27163433@gyda.ifi.uio.no> \<ENAG.91May29011708@gyda.ifi.uio.no> \<ENAG.91May29102312@gyda.ifi.uio.no> \<ENAG.91Nov26184624@gyda.ifi.uio.no> \<ENAG.91Nov26195814@gyda.ifi.uio.no> \<ENAG.91Nov27180232@gyda.ifi.uio.no> \<ENAG.91Nov28232706@gyda.ifi.uio.no> \<ENAG.91Nov8040530@gyda.ifi.uio.no> \<ENAG.91Oct10100026@gyda.ifi.uio.no> \<ENAG.91Oct12040520@gyda.ifi.uio.no> \<ENAG.91Oct1225909@gyda.ifi.uio.no> \<ENAG.91Oct2124204@gyda.ifi.uio.no> \<ENAG.91Oct28172111@gyda.ifi.uio.no> \<ENAG.91Oct28172818@gyda.ifi.uio.no> \<ENAG.91Oct29230246@gyda.ifi.uio.no> \<ENAG.91Oct3230648@gyda.ifi.uio.no> \<ENAG.91Oct9030958@gyda.ifi.uio.no> \<ENAG.91Sep11204921@gyda.ifi.uio.no> \<ENAG.91Sep13131229@gyda.ifi.uio.no> \<ENAG.91Sep15015117@gyda.ifi.uio.no> \<ENAG.91Sep18033841@gyda.ifi.uio.no> \<ENAG.91Sep19103338@gyda.ifi.uio.no> \<ENAG.91Sep19104844@gyda.ifi.uio.no> \<ENAG.91Sep20165021@gyda.ifi.uio.no> \<ENAG.91Sep26044723@gyda.ifi.uio.no> \<ENAG.91Sep26160350@gyda.ifi.uio.no> \<ENAG.91Sep29035923@gyda.ifi.uio.no> \<ENAG.91Sep8021352@gyda.ifi.uio.no> \<ENAG.91Sep9053335@gyda.ifi.uio.no> \<ENAG.92Feb8045527@gyda.ifi.uio.no> \<ENAG.92Mar16232216@gyda.ifi.uio.no> \<GNAT.91Jun19182452@kauri.kauri.vuw.ac.nz> \<HMUELNER.91Nov11190410@neptun.iicm.tu-graz.ac.at> \<HMUELNER.91Nov7153744@neptun.iicm.tu-graz.ac.at> \<HT.92Jan21095924@barclay.cogsci.ed.ac.uk> \<JBD.91May7140437@dasteel.uucp> \<JJC.91Aug4114803@jclark.UUCP> \<JJC.91Aug5114846@jclark.UUCP> \<JJC.91Jul1132213@jclark.UUCP> \<JJC.91Jun27115235@jclark.UUCP> \<JJC.91May15122300@jclark.UUCP> \<JJC.91May8150350@jclark.UUCP> \<JJC.91Nov13102755@jclark.com> \<JJC.91Nov30151055@jclark.com> \<JJC.91Oct28110544@jclark.com> \<JJC.92Feb11171929@jclark.com> \<JJC.92Feb17233040@jclark.com> \<JJC.92Feb23142941@jclark.com> \<JJC.92Feb23151726@jclark.com> \<JJC.92Feb7205012@jclark.com> \<JJC.92Jan13093130@jclark.com> \<JJC.92Jan13094854@jclark.com> \<JJC.92Jan13100916@jclark.com> \<JJC.92Jan13102425@jclark.com> \<JJC.92Jan13220053@jclark.com> \<JJC.92Jan21111754@jclark.com> \<JJC.92Jan29131441@jclark.com> \<JJC.92Jan31113600@jclark.com> \<JJC.92Jan5110917@jclark.com> \<JJC.92Jan6120624@jclark.com> \<JJC.92Jan6124949@jclark.com> \<JJC.92Jan6132428@jclark.com> \<JJC.92Jan6141935@jclark.com> \<KONHKS.92Jan15103648@euas20.ericsson.se> \<MCLAY.91Jun6123541@dog.cme.nist.gov> \<MEGGIN.92Mar16160845@epas.utoronto.ca> \<MILES.91Aug21205227@scott.cogsci.ed.ac.uk> \<MILES.91Jul17165635@oliphant.cogsci.ed.ac.uk> \<MILES.91Jul31155839@oliphant.cogsci.ed.ac.uk> \<NAITO.91Aug22190452@casp5.cis.canon.co.jp> \<NAITO.91Jul2175553@casp5.cis.canon.co.jp> \<NAITO.91Oct28185000@casp5.cis.canon.co.jp> \<PREECE.92Feb14102808@neptune.urbana.mcd.mot.com> \<PREECE.92Jan10115045@neptune.urbana.mcd.mot.com> \<RDURANT.92Jan20151219@rdurant.mentor.com> \<RDURANT.92Jan21123529@rdurant.mentor.com> \<RSW.91Dec4234037@fiddle.cs.brown.EDU> \<SPQR.92Jan6165515@hilliard.ecs.soton.ac.uk> \<SPQR.92Jan9130339@hilliard.ecs.soton.ac.uk> \<TED.91Sep16100351@ithaka.nmsu.edu> \<TED.92Feb3232256@lole.nmsu.edu> \<TED.92Feb3234015@lole.nmsu.edu> \<TED.92Feb5100233@lole.nmsu.edu> \<TED.92Jan31200816@lole.nmsu.edu> \<YdlULwG00hMg4IuUYi@cs.cmu.edu> \<ZRi9cB3w164w@knex.Gwinnett.COM> \<bewqy1.5mi@wang.com> \<ccnsKkg000001D0EZz@andrew.cmu.edu> \<cdW_NRa00hMg52ckR3@cs.cmu.edu> \<eden.686591399@rlxdev> \<eden.686943497@rlxdev> \<jos.677402265@freyr> \<jos.684428248@freyr> \<jos.685797190@freyr> \<jos.686225600@freyr> \<jos.693565839@freyr> \<jyfm7-#@rpi.edu> \<ke4k9dINNikv@shelley.aa.ox.com> \<kqktrsINNqk0@agate.berkeley.edu> \<msf.691880493@phobos> \<nickyc.696133656@extro.ucc.su.OZ.AU> \<odQosKr0Bwxd0NO3kX@transarc.com> \<pgrrjpb@rpi.edu> \<ricko.698914414@ee.uts.EDU.AU> \<tomw.694843664@ccadfa> \<tyfmfb#@rpi.edu> /pub/SIGhyper: -rw-r--r-- 1 enag enag 6258 Apr 29 1991 1991-001 drwxr-xr-x 4 enag enag 512 Oct 14 00:14 ARC-SGML -rw-r--r-- 1 enag enag 25649 Nov 20 19:09 DIS10744.TOC -rw-r--r-- 1 enag enag 3984 Dec 4 21:04 DTR10037.TOC -rw-r--r-- 1 enag enag 134981 Oct 14 16:22 Directory.ps -rw-r--r-- 1 enag enag 66884 Nov 2 17:17 HyTime.DTD -rw-r--r-- 1 enag enag 1205 Nov 11 02:16 README lrwxrwxrwx 1 root enag 8 Jan 12 22:20 SGMLUG -> ARC-SGML -rw-r--r-- 1 enag enag 16266 Sep 28 22:05 SIGhyper.info -rw-r--r-- 1 enag enag 71048 Sep 28 22:19 application.ps -rw-r--r-- 1 enag enag 6447 Sep 28 22:14 application.tex -rw-r--r-- 1 enag enag 178506 Oct 14 16:21 info-letter.ps -rw-r--r-- 1 enag enag 3435 Nov 9 15:57 newsletter.1.1 /pub/SIGhyper/ARC-SGML: drwxr-xr-x 2 enag enag 512 Oct 10 07:00 distrib drwxr-xr-x 2 enag enag 512 Feb 11 21:08 jclark /pub/SIGhyper/ARC-SGML/distrib: -r--r--r-- 1 enag enag 60957 Jul 19 1991 arcrexx.exe -r--r--r-- 1 enag enag 113776 Jul 19 1991 arcsgmlc.exe -r--r--r-- 1 enag enag 72136 Jul 19 1991 arcsgmlh.exe -r--r--r-- 1 enag enag 58041 Jul 19 1991 arctest.exe -r--r--r-- 1 enag enag 50460 Jul 19 1991 arcvm2.exe -r--r--r-- 1 enag enag 140124 Jul 19 1991 pkz110ex.exe -r--r--r-- 1 enag enag 2274 Jul 19 1991 readme /pub/SIGhyper/ARC-SGML/jclark: -r--r--r-- 1 enag enag 921600 Sep 2 1991 arcsgml-1.0jclark.tar -r--r--r-- 1 enag enag 757760 Oct 28 18:23 sgmls-0.3.tar -r--r--r-- 1 enag enag 901120 Jan 20 21:47 sgmls-0.5.tar -r--r--r-- 1 enag enag 952320 Feb 11 19:44 sgmls-0.6.tar -------------------- MAILER.CC.FSU.EDU -------------------- /pub/sgml: -rw-r--r-- 1 3120 41 6258 Sep 29 20:39 1991-001 drwxr-xr-x 2 3120 41 512 Jul 20 1991 ARC-SGML drwxr-xr-x 2 3120 41 512 Jan 7 14:42 ARC-SGML.MAC drwxr-xr-x 2 3120 41 512 Aug 5 1991 ARC-SGML.UNIX drwxr-xr-x 2 3120 41 512 Feb 9 15:20 DAVENPORT drwxr-xr-x 2 3120 41 512 Nov 1 11:16 HYTIME -rw-r--r-- 1 3120 41 1074 Nov 23 10:22 README drwxr-xr-x 2 3120 41 512 Feb 9 10:27 SGMLS -rw-r--r-- 1 3120 41 16386 Nov 23 10:25 SIGhyper.info -rw-r--r-- 1 3120 41 70649 Nov 23 10:39 applicationform.ps /pub/sgml/ARC-SGML: -rw-r--r-- 1 3120 41 60957 Jul 19 1991 arcrexx.exe -rw-r--r-- 1 3120 41 113776 Jul 19 1991 arcsgmlc.exe -rw-r--r-- 1 3120 41 72136 Jul 19 1991 arcsgmlh.exe -rw-r--r-- 1 3120 41 58041 Jul 19 1991 arctest.exe -rw-r--r-- 1 3120 41 50460 Jul 19 1991 arcvm2.exe -rw-r--r-- 1 3120 41 140124 Jul 19 1991 pkz110ex.exe -rw-r--r-- 1 3120 41 2274 Jul 19 1991 readme /pub/sgml/ARC-SGML.MAC: -rw-r--r-- 1 3120 41 12051 Jan 7 14:43 README -rw-r--r-- 1 3120 41 461687 Jan 7 14:25 arc-sgml-10.hqx /pub/sgml/ARC-SGML.UNIX: -rw-r--r-- 1 3120 41 289727 Aug 5 1991 arcsgml-1.0jclark.tar.Z /pub/sgml/DAVENPORT: -rw-r--r-- 1 3120 41 231689 Feb 9 16:20 dvnport1.ps.Z /pub/sgml/HYTIME: -rw-r--r-- 1 3120 41 67110 Nov 1 11:19 hytime.metaDTD /pub/sgml/SGMLS: -rw-r--r-- 1 3120 41 1624 Feb 9 10:27 README -rw-r--r-- 1 3120 41 2 Feb 9 10:19 Sgml.tar.Z -rw-r--r-- 1 3120 41 816053 Feb 9 10:19 sgml2latex-format.1.2.tar.Z -rw-r--r-- 1 3120 41 294412 Feb 9 10:19 sgmls-0.6.tar.Z -------------------- SGML1.EX.AC.UK -------------------- /pub: -r-xr-x--- 1 sgmlbox ecu 309 Jul 10 1991 .login drwxr-xr-x 2 MGPopham ecu 512 Feb 13 10:18 ISO8879.info -rw-r--r-- 1 MGPopham ecu 1625 Feb 24 09:30 README drwxr-xr-x 2 MGPopham ecu 512 Feb 20 11:00 arcsgml drwxr-xr-x 2 MGPopham ecu 512 Jan 16 17:05 bibliog d--x--x--x 2 root daemon 512 Dec 20 10:32 bin drwxr-xr-x 2 MGPopham ecu 512 Feb 24 09:17 davenport d--x--x--x 2 root daemon 512 Dec 20 10:34 dev d--x--x--x 2 root daemon 512 Dec 20 10:47 etc drwxr-xr-x 2 MGPopham ecu 512 Feb 19 11:15 format drwxr-xr-x 2 MGPopham ecu 512 Mar 19 16:48 sgml.project drwxr-xr-x 2 MGPopham ecu 512 Feb 14 11:37 sgml.uk drwxr-xr-x 2 MGPopham ecu 512 Feb 18 10:46 sgmls drwxrwxr-x 6 MGPopham ecu 512 Mar 12 13:54 tei d--x--x--x 3 root daemon 512 Dec 20 10:33 usr /pub/ISO8879.info: -rw-r--r-- 1 MGPopham ecu 654 Feb 14 09:34 README -rw-r--r-- 1 MGPopham ecu 30845 Feb 13 10:07 SGML.comments.DTD /pub/arcsgml: -rw-r--r-- 1 MGPopham ecu 4934 Feb 20 11:13 README -rw-r--r-- 1 MGPopham ecu 404959 Feb 20 11:00 arc-sgml-10.hqx.Z -rw-r--r-- 1 MGPopham ecu 60957 Jul 11 1991 arcrexx.exe -rw-r--r-- 1 MGPopham ecu 289727 Feb 19 09:42 arcsgml-1.0jclark.tar.Z -rw-r--r-- 1 MGPopham ecu 651190 Jan 24 10:15 arcsgml.tar.Z -rw-r--r-- 1 MGPopham ecu 113776 Jul 11 1991 arcsgmlc.exe -rw-r--r-- 1 MGPopham ecu 72136 Jul 11 1991 arcsgmlh.exe -rw-r--r-- 1 MGPopham ecu 58041 Jul 11 1991 arctest.exe -rw-r--r-- 1 MGPopham ecu 50460 Jul 11 1991 arcvm2.exe -rw-r--r-- 1 MGPopham ecu 140124 Jul 11 1991 pkz110ex.exe /pub/bibliog: -rw-r--r-- 1 MGPopham ecu 167963 Jan 15 15:11 Bib -rw-r--r-- 1 MGPopham ecu 77589 Jan 15 15:11 Bib.tar.Z -rw-r--r-- 1 MGPopham ecu 42206 Jan 15 15:11 Bibliog.p1 -rw-r--r-- 1 MGPopham ecu 42203 Jan 15 15:11 Bibliog.p2 -rw-r--r-- 1 MGPopham ecu 42106 Jan 15 15:11 Bibliog.p3 -rw-r--r-- 1 MGPopham ecu 41986 Jan 15 15:11 Bibliog.p4 -rw-r--r-- 1 MGPopham ecu 2969 Jan 15 15:12 README /pub/davenport: -rw-r--r-- 1 MGPopham ecu 859 Feb 24 09:26 README -rw-r--r-- 1 MGPopham ecu 223501 Feb 24 09:14 dvnport1.ps.Z /pub/format: -rw-r--r-- 1 MGPopham ecu 10719 Feb 19 11:39 README -rwxr--r-- 1 MGPopham ecu 816053 Feb 19 11:07 sgml2latex-format.1.2.tar.Z /pub/sgml.project: -rw-r--r-- 1 MGPopham ecu 1055 Mar 19 16:53 README -rw-r--r-- 1 MGPopham ecu 2434 Feb 14 11:30 info.001 -rw-r--r-- 1 MGPopham ecu 4023 Feb 14 11:58 questionnaire -rw-r--r-- 1 MGPopham ecu 29305 Feb 14 11:59 report.004 -rw-r--r-- 1 MGPopham ecu 6899 Feb 14 12:00 report.005 -rw-r--r-- 1 MGPopham ecu 12095 Feb 14 12:01 report.006 -rw-r--r-- 1 MGPopham ecu 43157 Feb 14 12:05 report.007 -rw-r--r-- 1 MGPopham ecu 30390 Mar 19 16:48 report.008 /pub/sgml.uk: -rw-r--r-- 1 MGPopham ecu 235 Feb 14 11:39 README -rw-r--r-- 1 MGPopham ecu 3162 Feb 14 11:47 notice.001 /pub/sgmls: -rw-r--r-- 1 MGPopham ecu 2260 Feb 18 11:08 README -rwxr--r-- 1 MGPopham ecu 294412 Feb 18 10:44 sgmls-0.6.tar.Z /pub/tei: drwxrwxr-x 2 MGPopham ecu 512 Mar 11 15:49 intro drwxrwxr-x 2 MGPopham ecu 1024 Mar 12 13:54 p1 drwxrwxr-x 5 MGPopham ecu 512 Mar 11 15:54 p2 drwxrwxr-x 2 MGPopham ecu 512 Mar 16 09:41 tech /pub/tei/p1: -rwxr--r-- 1 MGPopham ecu 8802 Mar 11 15:53 TEI1.DTD -rwxr--r-- 1 MGPopham ecu 2200 Mar 11 15:53 TEIBACK1.DTD -rwxr--r-- 1 MGPopham ecu 4823 Mar 11 15:53 TEIBASE1.DTD -rwxr--r-- 1 MGPopham ecu 8106 Mar 11 15:53 TEICRYS1.DTD -rwxr--r-- 1 MGPopham ecu 6624 Mar 11 15:53 TEIDRAM1.DTD -rwxr--r-- 1 MGPopham ecu 3887 Mar 11 15:53 TEIFRON1.DTD -rwxr--r-- 1 MGPopham ecu 15479 Mar 11 15:53 TEIHDR1.DTD -rwxr--r-- 1 MGPopham ecu 5428 Mar 11 15:53 TEILING1.DTD -rwxr--r-- 1 MGPopham ecu 7459 Mar 11 15:53 TEILOW1.DTD -rwxr--r-- 1 MGPopham ecu 3201 Mar 11 15:53 TEIREND1.DTD -rwxr--r-- 1 MGPopham ecu 3791 Mar 11 15:53 TEITC1.DTD -rwxr--r-- 1 MGPopham ecu 3431 Mar 11 15:53 TEIWSD1.DTD /pub/tei/p2: drwxrwxr-x 2 MGPopham ecu 512 Mar 12 13:55 decls drwxrwxr-x 2 MGPopham ecu 512 Mar 11 15:54 drafts drwxrwxr-x 2 MGPopham ecu 512 Mar 11 15:53 dtds /pub/tei/p2/decls: -rwxr--r-- 1 MGPopham ecu 4924 Mar 11 16:00 ISOCYR1.ENTITIES -rwxr--r-- 1 MGPopham ecu 2539 Mar 11 16:00 ISOCYR2.ENTITIES -rwxr--r-- 1 MGPopham ecu 1673 Mar 11 16:00 ISODIA.ENTITIES -rwxr--r-- 1 MGPopham ecu 3804 Mar 11 16:00 ISOGRK1.ENTITIES -rwxr--r-- 1 MGPopham ecu 2353 Mar 11 16:00 ISOGRK2.ENTITIES -rwxr--r-- 1 MGPopham ecu 4885 Mar 11 16:00 ISOLAT1.ENTITIES -rwxr--r-- 1 MGPopham ecu 7982 Mar 11 16:00 ISOLAT2.ENTITIES -rwxr--r-- 1 MGPopham ecu 5402 Mar 11 16:00 ISONUM.ENTITIES -rwxr--r-- 1 MGPopham ecu 6059 Mar 11 16:00 ISOPUB.ENTITIES -rwxr--r-- 1 MGPopham ecu 4304 Mar 11 16:00 TEIARB.ENTITIES -rwxr--r-- 1 MGPopham ecu 2983 Mar 11 16:00 TEICOP.ENTITIES -rwxr--r-- 1 MGPopham ecu 17804 Mar 11 16:00 TEIGRK.ENTITIES -rwxr--r-- 1 MGPopham ecu 15928 Mar 11 16:00 TEIIPA.ENTITIES /pub/tei/tech: -rwxr--r-- 1 MGPopham ecu 14854 Mar 11 15:52 TR1W4.TEI1 --------------------------------------------------------------------------- -- Erik Naggum | +47-295-0313 | ISO 8879 SGML | Memento, Naggum Software | | DIS 10744 HyTime | terrigena. Boks 1570, Vika | \<erik@naggum.no> | JTC 1/SC 18/WG 8 | Memento, 0118 OSLO, NORWAY | \<enag@ifi.uio.no> | SGML UG SIGhyper | vita brevis. </message> <message id="<JBW.92Mar26005442@bigbird.bu.edu>" date="2910578082"> Newsgroups: comp.emacs,comp.text.sgml Followup-To: comp.emacs Date: 26 Mar 1992 05:54:42 UT From: Joe Wells \<jbw@bigbird.bu.edu> Organization: Boston University Computer Science Department Message-ID: \<JBW.92Mar26005442@bigbird.bu.edu> References: <1992Mar16.152312.20696@epas.toronto.edu> <23055B@erik.naggum.no> \<MEGGIN.92Mar16160845@epas.utoronto.ca> \<YdlULwG00hMg4IuUYi@cs.cmu.edu> <23057C@erik.naggum.no> Subject: Re: sgml-mode for emacs? Have any of you ever seen Leif? Leif is an extension to GNU Emacs that handles the parsing-from-the-beginning-of-the-document problem by communicating with a separate process that keeps a parse tree that is adjusted whenever a change is made to the buffer. I don't remember how they dealt with ungrammatical buffers ... Anyway, I believe it would be helpful for an SGML mode for Emacs. -- Enjoy, Joe Wells \<jbw@cs.bu.edu> Member of the League for Programming Freedom --- send e-mail for details </message> <message id="<JJC.92Mar26121808@jclark.com>" date="2910597488"> Newsgroups: comp.text.sgml,gnu.emacs.sources Followup-To: comp.text.sgml Date: 26 Mar 1992 11:18:08 UT From: James Clark \<jjc@jclark.com> Organization: None, London, England Message-ID: \<JJC.92Mar26121808@jclark.com> Subject: sgml-mode.el Here's a simple SGML mode for GNU Emacs. Comments and suggestions for improvements are welcome. James Clark jjc@jclark.com ;; SGML mode. ;; Copyright (C) 1992 James Clark (jjc@jclark.com) ;; Parts derived from blink-matching-open in simple.el, which is ;; Copyright (C) 1985, 1986, 1987 Free Software Foundation, Inc. ;; This file is not yet part of GNU Emacs. ;; GNU Emacs is free software; you can redistribute it and/or modify ;; it under the terms of the GNU General Public License as published by ;; the Free Software Foundation; either version 1, or (at your option) ;; any later version. ;; GNU Emacs is distributed in the hope that it will be useful, ;; but WITHOUT ANY WARRANTY; without even the implied warranty of ;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the ;; GNU General Public License for more details. ;; You should have received a copy of the GNU General Public License ;; along with GNU Emacs; see the file COPYING. If not, write to ;; the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA. ;; Some suggestions for your .emacs file: ;; ;; (autoload 'sgml-mode "sgml-mode" "SGML mode" t) ;; ;; (setq auto-mode-alist ;; (append (list (cons "\\\\.sgm$" 'sgml-mode) ;; (cons "\\\\.sgml$" 'sgml-mode) ;; (cons "\\\\.dtd$" 'sgml-mode)) ;; auto-mode-alist)) (provide 'sgml-mode) (require 'compile) ;;; sgmls is a free SGML parser available from ;;; ftp.uu.net:pub/text-processing/sgml ;;; Its error messages can be parsed by next-error. ;;; The -s option suppresses output. (defconst sgml-validate-command "sgmls -s" "The command to validate an SGML document. The file name of current buffer file name will be appended to this, separated by a space.") (defvar sgml-saved-validate-command nil "The command last used to validate in this buffer.") (defvar sgml-mode-map nil "Keymap for SGML mode") (if sgml-mode-map () (setq sgml-mode-map (make-sparse-keymap)) (define-key sgml-mode-map ">" 'sgml-close-angle) (define-key sgml-mode-map "/" 'sgml-slash) (define-key sgml-mode-map "\\C-c\\C-v" 'sgml-validate)) (defun sgml-mode () "Major mode for editing SGML. Makes > display the matching <. Makes / display matching /. Use \\\\[sgml-validate] to validate your document with an SGML parser." (interactive) (kill-all-local-variables) (setq local-abbrev-table text-mode-abbrev-table) (use-local-map sgml-mode-map) (setq mode-name "SGML") (setq major-mode 'sgml-mode) (make-local-variable 'paragraph-start) ;; A start or end tag by itself on a line separates a paragraph. ;; This is desirable because SGML discards a newline that appears ;; immediately after a start tag or immediately before an end tag. (setq paragraph-start "^[ \\t\\n]\\\\|\\ \\\$</?\\\\([A-Za-z]\\\\([-.A-Za-z0-9= \\t\\n]\\\\|\\"[^\\"]\\"\\\\|'[^']'\\\$\\\\)?>$\\\\)") (make-local-variable 'paragraph-separate) (setq paragraph-separate "^[ \\t\\n]$\\\\|\\ ^</?\\\$[A-Za-z]\\\\([-.A-Za-z0-9= \\t\\n]\\\\|\\"[^\\"]\\"\\\\|'[^']'\\\$\\\\)?>$") (make-local-variable 'sgml-saved-validate-command) (set-syntax-table text-mode-syntax-table) (make-local-variable 'comment-start) (setq comment-start "\") (make-local-variable 'comment-indent-hook) (setq comment-indent-hook 'sgml-comment-indent) (make-local-variable 'comment-start-skip) ;; This will allow existing comments within declarations to be ;; recognized. (setq comment-start-skip "--[ \\t]") (run-hooks 'text-mode-hook 'sgml-mode-hook)) (defun sgml-comment-indent () (if (and (looking-at "--") (not (and (eq (char-after (1- (point))) ?!) (eq (char-after (- (point) 2)) ?<)))) (progn (skip-chars-backward " \\t") (max comment-column (1+ (current-column)))) 0)) (defconst sgml-start-tag-regex "<[A-Za-z]\\\$[-.A-Za-z0-9= \\n\\t]\\\\|\\"[^\\"]\\"\\\\|'[^']'\\\$" "Regular expression that matches a non-empty start tag. Any terminating > or / is not matched.") (defvar sgml-mode-markup-syntax-table nil "Syntax table used for scanning SGML markup.") (if sgml-mode-markup-syntax-table () (setq sgml-mode-markup-syntax-table (make-syntax-table)) (modify-syntax-entry ?< "(>" sgml-mode-markup-syntax-table) (modify-syntax-entry ?> ")<" sgml-mode-markup-syntax-table) (modify-syntax-entry ?- "_ 1234" sgml-mode-markup-syntax-table) (modify-syntax-entry ?\\' "\\"" sgml-mode-markup-syntax-table)) (defconst sgml-angle-distance 4000 "If non-nil, is the maximum distance to search for matching < when > is inserted.") (defun sgml-close-angle (arg) "Insert > and display matching <." (interactive "p") (insert-char ?> arg) (if (> arg 0) (let ((oldpos (point)) (blinkpos)) (save-excursion (save-restriction (if sgml-angle-distance (narrow-to-region (max (point-min) (- (point) sgml-angle-distance)) oldpos)) ;; See if it's the end of a marked section. (and (> (- (point) (point-min)) 3) (eq (char-after (- (point) 2)) ?\\]) (eq (char-after (- (point) 3)) ?\\]) (re-search-backward "<!\\\\[\\\$-?[A-Za-z0-9. \\t\\n&;]\\\\|\\ --\\\\([^-]\\\\|-[^-]\\\$--\\\\)\\\\[" (point-min) t) (let ((msspos (point))) (if (and (search-forward "\]]>" oldpos t) (eq (point) oldpos)) (setq blinkpos msspos)))) ;; This handles cases where the > ends one of the following: ;; markup declaration starting with <! (possibly including a ;; declaration subset); start tag; end tag; SGML declaration. (if blinkpos () (goto-char oldpos) (condition-case () (let ((oldtable (syntax-table)) (parse-sexp-ignore-comments t)) (unwind-protect (progn (set-syntax-table sgml-mode-markup-syntax-table) (setq blinkpos (scan-sexps oldpos -1))) (set-syntax-table oldtable))) (error nil)) (and blinkpos (goto-char blinkpos) (or ;; Check that it's a valid delimiter in context. (not (looking-at "<\\\$\\\\?\\\\|/?[A-Za-z>]\\\\|!\\\\([[A-Za-z]\\\\|--\\\$\\\\)")) ;; Check that it's not a net-enabling start tag ;; nor an unclosed start-tag. (looking-at (concat sgml-start-tag-regex "[/<]")) ;; Nor an unclosed end-tag. (looking-at "</[A-Za-z][-.A-Za-z0-9][ \\t]<")) (setq blinkpos nil))) (if blinkpos () ;; See if it's the end of a processing instruction. (goto-char oldpos) (if (search-backward "\<?" (point-min) t) (let ((pipos (point))) (if (and (search-forward ">" oldpos t) (eq (point) oldpos)) (setq blinkpos pipos)))))) (if blinkpos (progn (goto-char blinkpos) (if (pos-visible-in-window-p) (sit-for 1) (message "Matches %s" (buffer-substring blinkpos (progn (end-of-line) (point))))))))))) ;;; I doubt that null end tags are used much for large elements, ;;; so use a small distance here. (defconst sgml-slash-distance 1000 "If non-nil, is the maximum distance to search for matching / when / is inserted.") (defun sgml-slash (arg) "Insert / and display any previous matching /. Two /s are treated as matching if the first / ends a net-enabling start tag, and the second / is the corresponding null end tag." (interactive "p") (insert-char ?/ arg) (if (> arg 0) (let ((oldpos (point)) (blinkpos) (level 0)) (save-excursion (save-restriction (if sgml-slash-distance (narrow-to-region (max (point-min) (- (point) sgml-slash-distance)) oldpos)) (if (and (re-search-backward sgml-start-tag-regex (point-min) t) (eq (match-end 0) (1- oldpos))) () (goto-char (1- oldpos)) (while (and (not blinkpos) (search-backward "/" (point-min) t)) (let ((tagend (save-excursion (if (re-search-backward sgml-start-tag-regex (point-min) t) (match-end 0) nil)))) (if (eq tagend (point)) (if (eq level 0) (setq blinkpos (point)) (setq level (1- level))) (setq level (1+ level))))))) (if blinkpos (progn (goto-char blinkpos) (if (pos-visible-in-window-p) (sit-for 1) (message "Matches %s" (buffer-substring (progn (beginning-of-line) (point)) (1+ blinkpos)))))))))) (defun sgml-validate (command) "Validate an SGML document. Runs COMMAND, a shell command, in a separate process asynchronously with output going to the buffer compilation. You can then use the command \\\\[next-error] to find the next error message and move to the line in the SGML document that caused it." (interactive (list (read-string "Validate command: " (or sgml-saved-validate-command (concat sgml-validate-command " " (let ((name (buffer-file-name))) (and name (file-name-nondirectory name)))))))) (setq sgml-saved-validate-command command) (compile1 command "No more errors")) </message> <message id="<23067E@erik.naggum.no>" date="2910634800"> Newsgroups: comp.text.sgml Date: 26 Mar 1992 21:40:00 UT From: Erik Naggum \<erik@naggum.no> Reply-To: Erik Naggum \<enag@ifi.uio.no> Organization: Naggum Software, Oslo, Norway Message-ID: <23067E@erik.naggum.no> References: \<JJC.92Mar26121808@jclark.com> Subject: Re: sgml-mode.el James Clark's simple SGML mode is now also available in the FTP archive, as well as in the comp.text.sgml archive at ftp.ifi.uio.no, in the new directory /pub/SGML/elisp, file "sgml-mode.el". Thanks, James. I'm impressed, and it's not the first time. Cheers, \</Erik> -- Erik Naggum | +47-295-0313 | ISO 8879 SGML | Memento, Naggum Software | | DIS 10744 HyTime | terrigena. Boks 1570, Vika | \<erik@naggum.no> | JTC 1/SC 18/WG 8 | Memento, 0118 OSLO, NORWAY | \<enag@ifi.uio.no> | SGML UG SIGhyper | vita brevis. </message> <message id="<1992Mar27.033842.13992@sq.sq.com>" date="2910656322"> Newsgroups: comp.text.sgml Date: 27 Mar 1992 03:38:42 UT From: Mark Brader \<msb@sq.sq.com> Organization: SoftQuad Inc., Toronto, Canada Message-ID: <1992Mar27.033842.13992@sq.sq.com> References: <1992Mar24.073931.16933@bohra.cpg.oz.au> <1992Mar24.180706.224@decvax.dec.com> Subject: Re: SGML Book > "The SGML Primer" is written and published by SoftQuad Inc. You can order > copies from them (is this a current address?): No. We're now at: 56 Aberfoyle Cr., Suite 810 Toronto, Canada M8X 2W4 Phone +1 416 239 4801 From USA 1-800-387-2777 Fax +1 416 239 7105 -- Mark Brader, SoftQuad Inc., "Verbose better." Toronto, utzoo!sq!msb, msb@sq.com -- David M. Sherman </message> <message id="<JJC.92Mar28104346@jclark.com>" date="2910764626"> Newsgroups: comp.text.sgml Date: 28 Mar 1992 09:43:46 UT From: James Clark \<jjc@jclark.com> Organization: None, London, England Message-ID: \<JJC.92Mar28104346@jclark.com> Subject: sgmls 0.7 available Sgmls version 0.7 is now available for anonymous ftp from ftp.uu.net as pub/text-processing/sgml/sgmls-0.7.tar.Z (about 310k). An MS-DOS executable with formatted documentation is also available in the same place as sgmls0_7.zip (about 75k). I make no guarantee that this will work on any system at all, nor that it will not completely destroy your system. It was prepared on a Toshiba 286 portable running MS-DOS 4.01. Apart from bug fixes, this release has several improvements. The upper limit on NAMELEN has been increased to 239, and that on GRPCNT, GRPGTCNT, and GRPLVL to 253. All quantity limits apart from NORMSEP can now be increased (ignoring the DTAGLEN and DTEMPLEN quantities, which are irrelevant since sgmls does not support the DATATAG feature). There have also been some important internal improvements; in particular, storage for names is now dynamically allocated. Sgmls is an SGML parser derived from the ARCSGML parser materials which were written by Charles Goldfarb. It outputs a simple, easily parsed, line oriented, ASCII representation of an SGML document's Element Structure Information Set (see pp 588-593 of ``The SGML Handbook''). It is intended to be used as the front end for structure-controlled SGML applications. For compatibility with the Amsterdam SGML Parser (ASP), there is also a filter that translates the output of sgmls using an ASP replacement file. It is primarily intended for Unix systems, but it works also on MS-DOS. I've tested it with the following architecture/OS/compiler combinations: sparc/SunOS 4.1.1/cc, sparc/SunOS 4.1.1/gcc, 386/SVR3.2/cc, 286/MS-DOS/Borland C++ 2.0. It should be straightforward to port to most systems that have 8-bit bytes, a character set consistent with ISO 646 IRV, and a reasonably modern C compiler. Please report any bugs to me. James Clark jjc@jclark.com </message> <message id="<23071C@erik.naggum.no>" date="2910812761"> Newsgroups: comp.text.sgml Date: 28 Mar 1992 23:06:01 UT From: Erik Naggum \<erik@naggum.no> Reply-To: Erik Naggum \<enag@ifi.uio.no> Organization: Naggum Software, Oslo, Norway Message-ID: <23071C@erik.naggum.no> References: \<JJC.92Mar28104346@jclark.com> Subject: Re: sgmls 0.7 available James Clark \<jjc@jclark.com> writes: | | Sgmls version 0.7 is now available for anonymous ftp from ftp.uu.net | as pub/text-processing/sgml/sgmls-0.7.tar.Z (about 310k). ... as well as ftp.ifi.uio.no in /pub/SIGhyper/ARC-SGML/jclark and mailer.cc.fsu.edu in /pub/sgml/SGMLS, both with the file name sgmls-0.7.tar.Z. (ftp.ifi.uio.no also has an uncompressed version, if you'd rather have that.) As far as I can tell from playing with this thing for a couple hours (after spending no more than 10 minutes compiling it!), is that this version has fixed even more bugs and anomalies found in the original distribution. (I still want to talk to the parser via function calls, and not another "language" I need to parse, though, in particular because I want to tell it things, too, not just listen.) Regards, \</Erik> -- Erik Naggum | +47-295-0313 | ISO 8879 SGML | Memento, Naggum Software | | DIS 10744 HyTime | terrigena. Boks 1570, Vika | \<erik@naggum.no> | JTC 1/SC 18/WG 8 | Memento, 0118 OSLO, NORWAY | \<enag@ifi.uio.no> | SGML UG SIGhyper | vita brevis. </message> <message id="<1992Mar30.185505.10613@sq.sq.com>" date="2910970505"> Newsgroups: comp.text.sgml Date: 30 Mar 1992 18:55:05 UT From: Yuri Rubinsky \<yuri@sq.sq.com> Organization: SoftQuad Inc., Toronto, Canada Message-ID: <1992Mar30.185505.10613@sq.sq.com> Keywords: basics, dtds, book Summary: Availability of SGML Primer v3.0 Subject: Re: Introductory SGML Books Regarding SoftQuad's little publication, The SGML Primer, Erik Naggum \<enag@ifi.uio.no> writes in <23066B@erik.naggum.no>: > I'm surprised that somebody from SoftQuad has not come out and > announced the availability of this new version now that people are > practially begging for it. > Are you there, SoftQuad? Thanks to Erik for his reminder that we should have posted an announcement of this! Version 3.0 of the SGML Primer is now available, at a cost of $10 (US), from SoftQuad at the address in my signature below. Eve Maler posted a quite helpful description of what the Primer is and isn't. I agree that this is not a hardcopy FAQ, nor a beginners' guide for creating instances; nor was it meant to be. The subtitle says what we had in mind: "SoftQuad's Quick Reference Guide to the Essentials of the Standard: The SGML Needed for Reading a DTD and Marked-Up Documents and Discussing Them Reasonably." As such, we've found the book very useful in our training classes; and the feedback we've received is that it has also helped beginners at the SGML '90 and '91 conferences follow the more technical goings-on. We recommend it for people with an interest in the behind-the-scenes SGML, not those who want to keep their distance from the details. Version 3 does indeed take account of the comments submitted by Erik and others, and for which we're very grateful. An example of one comment that didn't change the text: Erik writes: > Version 2.0 ... is misleading on empty elements (who have > end-tags in their examples, illegal by the language) ... The illustrative samples, a few of which appear in the book, come from screen shots of Author/Editor, our Mac/DOS/UNIX SGML-sensitive word processor slash editor. The software is designed to be usable by anyone with a text task to accomplish, SGML novice or aficionado. The start- and end-icons for elements are there to mark the containers. The majority of our users are not SGML experts, and they find this concept easier to learn and instantly work with than what seem to them complex and arbitrary rules about which tags must be included, which may be left off, and which must be left off. In Author/Editor, an element may or may not contain character data or other elements, or be EMPTY. The users needn't be concerned: an empty element looks the same as any other on the screen, but A/E won't let you type or insert elements inside. And of course, on export, the SGML stream created is completely valid: the empty element comes out with only a start-tag. Erik missed the explanatory note on page 4 which makes it clear that sample document instances sometimes appear "in the on-screen form used by ... Author/Editor". Some of the confusion may have come from the fact that in one case, a joke about floods before Noah consisting of any number of water elements, the diagram shows only water start-icons, in a turbulent display. This may have muddied the waters. --------- Yuri Rubinsky (416) 239-4801 President (800) 387-2777 (from U.S. only) SoftQuad Inc. uucp: {uunet,utzoo}!sq!yuri Suite 810, 56 Aberfoyle Cres. Internet: yuri@sq.com Toronto, Ontario, Canada M8X 2W4 Fax: (416) 239-7105 </message> <message id="<MISEPPAL.92Mar31144614@klaava.Helsinki.FI>" date="2911034774"> Newsgroups: comp.text.sgml Date: 31 Mar 1992 12:46:14 UT From: Mika Seppala \<miseppal@klaava.Helsinki.FI> Organization: University of Helsinki Message-ID: \<MISEPPAL.92Mar31144614@klaava.Helsinki.FI> Subject: Euromath, a mathematical SGML editor based on Grif GRIF AND EUROMATH Paul Hardiman asked in a recent post about users' comments on Grif, a French editor for producing SGML files in a user friendly fashion. In response to his request I would like to report that a group of European mathematicians are basing a software system, Euromath, on the GRIF editor. At present Grif is a very good SGML editor for plain text with simple formulas. The Euromath project will enhance Grif with advanced capabilities for mathematical text. A two-way Grif <--> LaTeX converter will be provided. Some mathematicians belonging to the Euromath group have had development versions of Grif for a year or so. A 2-3 day presentation and demonstrations with on hands sessions was held in January in Exeter, England. User reactions were favourable, though to support more efficient work with mathematical documents, some further development is still needed. A preliminary version of Euromath will be released within the very near future for restricted distribution in the European Mathematical community. The first "full version" will be released early next year. It will be possible to follow the development by subscribing to the Euromath Bulletin (first issue, May, 1992), which will contain professional articles on computer-related items of interest to mathematicians as well as more "soft" items in relation to Euromath. Euromath Bulletin will be distributed to all mathematics departments in Europe. Individuals who are interested in ordering the Bulletin should write to emb@geom.helsinki.fi Specific user reactions on a larger scale must wait. A centre in Copenhagen, Euromath Center, will be responsible for user support. It may be possible to obtain information from that centre too at a later stage, though I recommend being informed via the Euromath Bulletin. Mika Seppala Editor of the Euromath Bulletin Department of Mathematics University of Helsinki Hallituskatu 15 SF-00100 Helsinki, Finland </message>