On Sat, 7 Nov 1998 15:42:05 +0100
Chris Rowley <[log in to unmask]> wrote to LATEX-L
: William F. Hammond wrote --
: > SGML is all about fast staged processing. It is not very much about
: > getting on to paper.
: That sounds like a reasonable summary of reality, if not theoretically
Well, maybe. But consider the fussy stuff about "look-ahead"
involved in DTD construction. (That slur aside, it's mainly a pain
for DTD construction, not for the use of SGML languages.)
Qualification: Each individual SGML-to-SGML should be fast. Of course,
if you compose them, the times add (or worse, depending on swapping).
Parser output is a nice linear stream. My impression is that
processors are NOT expected to seek but just to make one pass through it.
(Then I believe that some processors construct the whole thing in
memory as a tree.)
I've been using Megginson's sgmlspl/sgmlspm (stabilized Dec. '95),
which is event driven and, moreover, linear except for things that I
choose to remember along the way (global variables for subsequent
branching) and pieces of document (whole SGML elements) that I may
push into temporary abeyance while descending subtrees. The biggest
thing that I think sensible to so push is a paragraph.
Of course, SGMLSPM has a cross-reference facility just as LaTeX does
and if that is exercised by a document, then a complete second pass
using an auxiliary file, as with LaTeX, is required.
All one needs to do is write little functions in Perl. You don't need
to be lisp-enabled. And some of those functions are very easy.
When I'm ready to write an XML DTD that is nearly isomorphic to my
SGML DTD for "article", the SGML-to-XML transformation that I use to
make the type of *archival* document that I think the LANL preprint
site should use is going to be *very* linear.
: > There is a very lucrative and apparently profitable industry out there
: > lurking behind closed doors.
: ????? Doing what exactly? Or are the doors too firmly closed to see?
If you listen to the UseNet newsgroup "comp.text.sgml" long enough,
you will see it. Yes, the doors are locked. In fact, just to get
a copy of the definition of SGML from the ISO costs a substantial sum.
(Better to buy Charles Goldfarb's _SGML Handbook_.)
(But I expect that some young Ph.D.'s in math, rather than in computer
science, will turn out to be leaders in this growing industry, and I
find that pleasing to contemplate.)
: > I suggest that individuals should think in terms of multiple SGML
: > transformations as pre-processing for LaTeX. Some industrial strength
: > publishers *may* want to think in terms of multiple SGML transformations
: > as pre-processing to TeX directly.
: That is certainly an interesting question in general: staright to TeX
: vs via LaTeX.
: Limited expereince suggests that some mixture may be needed; but
: a lot depends on how and where the formatting is specified.
1. Megginson's sgmlspl/sgmlspm comes with docs that may be used to
test the package. The two enclosed demo processors are:
(a) DocBook to LaTeX
(b) DocBook to HTML
2. I think that for most individuals and most academic departments
processing to LaTeX to get to paper is the most sensible choice.
3. I am preparing demo processors from my DTD to (a) LaTeX and
(b) HTML and eventually maybe to other things but I am much too lazy
to code for straight TeX myself. It might be pleasant for those who
have been accustomed to writing papers in plain TeX.
4. I would like to see someone who is fluent in Texinfo volunteer to
code from my "article" dtd -- or something close to it -- to Texinfo.
Along the way it should then become obvious how to give math full
implementation there. Note in this regard, that GNU-emacs window
displays are becoming progressively more useful in this regard. And
as most vt100's are not actual hardware, those windows, which are
fixed font displays with algorithmic "styling", could begin to admit a
public standard for change of cursor position and more inter-line
space in order to accommodate superscripts and subscripts, maybe also
reasonable but crude fractions in displays.