Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!mit-eddie!uw-beaver!fluke!inc From: inc@tc.fluke.COM (Gary Benson) Newsgroups: comp.text.sgml Subject: Re: looking for more information Message-ID: <1990Nov28.105230.10365@tc.fluke.COM> Date: 28 Nov 90 10:52:30 GMT References: <200@tivoli.UUCP> Organization: John Fluke Mfg. Co., Inc., Everett, WA Lines: 57 In article <200@tivoli.UUCP> lark@tivoli.UUCP (Lar Kaufman) writes: >In article dms@aix03.aix.rpi.edu (david m schwartz) writes: >>Hello -- I became aware of SGML this fall. The folks at an exhibition booth >> at EP '90 (Electronic Publishing Conference held this year at ....... Then Lar spends a great deal of time and energy in a terrific posting that really lays out many of the basics of SGML. I nominate his posting for inclusion in a Frequently Asked Questions file for this newsgroup. Many other newsgroups are doing that, and I think this is one that could benefit greatly from it. In the groups using FAQ files, one person volunteers to maintain the file, others submit questions and/or answers for the file, and in whatever state it is in, the file is posted once per month in the newsgroup. Ithink it is a great idea, particularly for groups like this one that seem to have a large number of people looking for the basic information needed to pursue their interests further. I would volunteer for FAQ maintainer except that my knowledge of SGML is also pretty rudimentary. Any takers? My second topic concerns the concept of "implied markup". In my work at Fluke's technical publication department, we have used this concept for years, and I wonder if there are others who use it to the extent we do. Is there much interest in the field? Any good books? For those to whom implied markup is unfamiliar: the idea is that rather than ANY kind of "coding", the writer submits a manuscript in such a form that it's format is implied...for example, when the word "Figure", followed by a number in the form "n-n", appears on a line by itself, indented from the margin, the implication is that this is a figure title...a change of font size and face is called for, and some amount of room is required now to hold the figure implied by the figure title. I have been fascinated to learn how MUCH of this sort of information is available, even in text generated by someone those who do not know the implied markup "rules". For example, if you see a group of consecutive paragraphs at the same indent, preceded by numbers, you can be pretty sure you are looking at a numerical list. If the amount of indent gets larger and the paragraphs are now marked in consecutive alphabetical order, then you are looking at an alphabetical list nested in the numerical one...lesser amounts of indent imply the end of nesting. I suppose I should make clear that we are dealing with so-called "structured documents" here - not free-form ads, novels, magazines, what have you. The world of publishing has LOTS of things that I am sure would not fit into the scheme I have outlined, but for the kinds of technical documents we publish, it seems to provide solutions to many of our nagging publication problems. Sometimes I wonder if we are the only people actively pursuing this technique. We now use a computer program written in perl to glean this structural information and convert it into generic codes. This is how we separate form from content, and I wonder how others are doing the same. Are there other methods to keep the writing and formatting functions separate without requiring every writer to learn the local dialect of SGML or other generic coding? -- Gary Benson -=[ S M I L E R ]=- -_-_-_-inc@fluke.com_-_-_-_-_-_-_-_-_-_- The first rule of intelligent tinkering is to save all the parts. -Paul Erlich