From LJM@SLACVM.BITNET Wed Aug 26 23:07:59 1992 Received: from vm.uni-c.dk by dkuug.dk via EUnet with SMTP (5.64+/8+bit/IDA-1.2.8) id AA00305; Wed, 26 Aug 92 23:07:59 +0200 Message-Id: <9208262107.AA00305@dkuug.dk> Received: from vm.uni-c.dk by vm.uni-c.dk (IBM VM SMTP V2R2) with BSMTP id 0817; Wed, 26 Aug 92 23:08:45 DNT Received: from SLACVM.SLAC.STANFORD.EDU by vm.uni-c.dk (Mailer R2.07) with BSMTP id 2701; Wed, 26 Aug 92 23:08:44 DNT Received: by SLACVM (Mailer R2.08 R208004) id 6533; Wed, 26 Aug 92 14:06:02 PST Date: Wed, 26 Aug 1992 12:12 -0800 (PST) From: "Len Moss" To: "SC22/WG5 Mailing List" Subject: Re: (SC22WG5.184) Processing Words, Part XIV X-Charset: ASCII X-Char-Esc: 29 In-Reply-To: walt@netcom.com -- 08/26/92 11:52 >I seem to be put in the position of defending TeX, troff, SGML, etc. >I am open to all suggestions and seek real information and debate. >But I must keep asking when I get answers that don't make any sense to me. Sorry, Walt, for letting you carry the ball on the "markup" side of this discussion (if only by asking revealing questions), but you've been doing an excellent job so I've been lazy enough to let you run with it ;-) For what it's worth, I strongly endorse some sort of generalized markup language rather than any specific word processing or desktop publishing program (I already responded directly to Jerry on this point, but I guess I should have responded to the whole list). Here are my replies to Walt's questions: > >1. Should the system be able to produce PostScript output and ascii versions > that correspond, line for line, with the PS version? Is either one > without the other sufficient? Or must every reader have the system to > process the document (e.g., Frame or Word or TEX)? The system available to the editor should be able to produce (at a minimum) a nicely formatted hardcopy, the corresponding PostScript file, and an ascii version that: is reasonably easy to read; preserves the structure (though not the formatting) of the document; makes the structure reasonably easy to understand; and can be easily correlated with the nicely formatted hardcopy. I don't believe the "correlation" requirement necessarily requires that the formatted hardcopy and the ascii version correspond line for line; that tends to make the ascii version much more difficult to read. There are other ways to establish adequate correlations, such as numbering (at least in the working drafts if the ISO style manual does not allow this in the final draft) every paragraph. Other members of the committee should not be required to use a specific tool in order to process the document, but should be able to select from a reasonable range of different tools (including ascii and a simple editor). For that matter, the editor should not have to commit to a specific tool for a complete revision cycle, but should be free to switch if a better tool comes along without impacting the rest of the committee. In other words, we should be standardizing on a portable file format and not on a particular tool. > >2. What are people not responsible for maintenance of the document expected > to be able to do with it? Certainly they should be able to read it to > find anything they want in it and use it to prepare proposals. Are > they expected to put proposals in a form that can be incorporated directy > into the document? Must every proposer have the system to process the > document (e.g., Frame or Word or TEX)? In addition to reading the document, people not responsible for its maintenance should be able to easily find and refer to specific portions of the text, search it in a variety of ways, and extract portions of it in a way that preserves the substructure as a starting point for writing proposals. They should not be required to put proposals in a particular format and we should not expect that approved proposals, even if carefully written, can be simply "plugged in" to the document without significant effort by the editor (as Walt points out, only the editor can really get it right). On the other hand, some sort of markup conventions are necessary to convey the intent of the proposal writer to the rest of the committee (as well as to the editor), and using the same (or at least a similar) markup style to write proposals and to maintain the document should be an advantage. > >3. Is it possible and reasonable to create simple tools to process the > source text (for example, to extract the syntax rules and create > the cross reference in Annex D)? Keith says we should not be in the business of creating tools. Certainly we should not waste time trying to create and maintain sophisticated, portable tools. Consider, however, what constitutes a "tool" -- if you include things like a complex GREP pattern, then of course we want to create tools. Using general purpose tools like GREP or an editor with a good macro facility, it is easy to produce a great variety of ad hoc views of a document. Embedded markup in the document (particularly structural rather than formatting markup) greatly extends the useful range of such easily-extracted views. (By the way, Walt described this as a question of primary concern to the editorial committee, but I think many other members will want such facilities also, so I'd classify it, in Walt's term, as an "outside" requirement.) > >4. Does the system must have powerful and flexible tools for creating > tables, equations, and possibly figures? It must be a system designed > to provide complete typographic control to the user (some test cases > might be to change the hyphenation of a particular word or slant the > third letter of some word 7 degrees left and set it in one point smaller > type). The system used by the editor certainly must have complete typographic control, and should probably have reasonably good, though not necessarily state of the art, facilities for tables, equations and figures. Other members of the committee don't need all these features. > >5. Do we want to get involved with a proprietary system (even if some of > the systems are provided free) in this era of "open systems" and > standards? Absolutely not, especially if one thinks in terms of a ten year revision cycle. By 1999 Frame and Word could easily appear as antiquated as SCRIPT or nroff on a line printer do today. -- Leonard J. Moss | My views don't necessarily Stanford Linear Accelerator Center, MS 97 | reflect those of SLAC, Stanford, CA 94309 | Stanford or the DOE