🚀 go-pugleaf

References: <1992Aug3.193817.2863@news.eng.convex.com> <BsFtBE.Hqq@watdragon.uwaterloo.ca> <23272E@erik.naggum.no>

Erik Naggum writes:

>  Even if presentation is so distant to our thinking that it no longer
>  matters, we should not disregard these factors and claim that structural
>  markup itself is sufficient.  This also means that any element structure
>  in which recursive elements are allowed is not context-free, but imposes
>  on the parser and/or the application a requirement that they know where
>  in the element structure they are at any given time.  I'm sure some will
>  find this very uncomfortable, though.

Ah, but this is the very power of SGML because any parser worth
its salt will always be able to tell an application exactly
where it is in the document tree, so it's *easy* for an application
to allow semantics applied against elements in different
contexts.  For example, in the SGML TextWrite editor, on-screen
presentation can be applied to elements in a variety of contexts
by specifying patterns applied against the fully-qualified generic
identifier (fqgi) of each element instance in the document.  Thus
I can associate different effects with a list item element
that appears at different levels of nesting within lists, and do
it easily (as opposed to having to write procedural code to do it).

By contrast, a processor like DCF BookMaster, which is not driven
by an SGML parser, must maintain all structure information itself.
Part of BookMaster's performance problem is the need to maintain
and validate that information.  DCF is very much context free, at
least to the degree it just takes input and goes, without significant
backtracking on parsing (if I understand parsing correctly, which
is highly doubtful, DCF is an LR(1) requiring lookahead of only
one character to correctly recognize all tokens).

Thus, rather than seeing lack of context freeness as a problem, I
see the services provided by an SGML parser as enabling applications
to deal effectively and efficiently with context-sensitive
processing problems.  But then I've never had to worry about the
number of mips my programs use--one of the few advantages of working
on large mainframes, I suppose.

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