| In other words, SGML, intended originally for users who would be
| working from a logical structure towards a formatted document, presumes
| that the logical structure is known to the user, whereas someone
| working from a formatted document towards code may find him or herself
| uncomfortably pushed towards speculation about logical structure.
this pushing would, presumably, be uncomfortable only when the ability to
modify the logical structure is made uncomfortable (as it is, with most
extant tools). if modification of structure with intelligent tracking of
inconsistencies were possible, a software system would be able to tell a
user what kind of choices in and departures from the logical structure
exist, without restricting the user to choose such structures prematurely.
unlike those who ascend to the pulpit of "success stories" and talk at
great length about their a priori or divine intuition about the structure
of their information, I believe that such structure is intuited from
exposure to information that is informally and intuitively conforming to a
concept of "type" such that this "type" is known first by its extension,
then gradually shaped into intension, against which future instances of the
type are supposed to conform. of course, at this point, non-conformance
may be indicative of weaknesses in instance as well as type. unless I am
gravely mistaken, the TEI has taken this approach for fairly large "types"
of documents for certain reasonably-well-known problem areas.
implementing such flexibility in SGML terms is non-trivial, but I continue
to find ways to make it well inside the feasible, provided one can take
some of the CPU power wasted on formatting and continuous screen updates of
graphical user interfaces, to instead do some computationally difficult
analysis. part of the reason you find glorified braindeath in the WYSIWYG
market is that computing power still has some way to go before you can both
waste all the CPU at dysfunctional window systems and still have some left
for real work. this does not mean that one should conclude that SGML tools
of necessity must be rigid enforcers of a largely unknown logical structure.
BTW, what SGML was and was not intended for is subject to the rewriting of
history that follows greater understanding of the problems that were both
intentionally and accidentally solved. what _was_ foresight and what "must
have been" foresight is often completely impossible to differentiate ex
post facto. and, equally, the opposite viewpoint holds. I suggest we
limit the discussion of SGML's intentions original or otherwise, and think
of ways in which we can use it, including ways in which we must extend it
to accomodate such uses. in other words, the issue you raise is important,
and too important to tie to some notion of SGML's "original intention".