🚀 go-pugleaf

In article <200@tivoli.UUCP> lark@tivoli.UUCP (Lar Kaufman) writes:
>In article <P!+^?5^@rpi.edu> 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