🚀 go-pugleaf

  If I understand Erik's explanation correctly, he is upset because I 
mean "application program" instead of "SGML application".  My actual 
comment was "SGML will result in non-portable, application-dependent 
documents", which is too unspecific.  I readily admit that in this
context, the inference that I meant "SGML application" is probable.
Erik is quite right to point out the distinction, and he's right that 
my knowledge of SGML is weak on this point.  E-mail from Steve DeRose,
on the other hand, reassures me that he at least wasn't confused by
my use of the term "application".  It's fair enough to request that I
not confuse the issue by using a term that already has a specific 
meaning, so let me reword my claim, and expand on it a bit:

      SGML will result in non-portable, applications-program-dependent 
      documents.

   Traditional database systems of the 50's and 60's suffered from
applications-program dependence.  They were based on a hierarchical
model (somewhat like SGML), but too much of the representation of the 
data crept into the design of applications-programs.  Some programs,
for example, manipulated the representation of data fields; others
made assumptions about the arrangement of the hierarchy that were
necessary to cram non-hierarchical data into a hierarchical form, but
that were otherwise not necessary.  The consequence of this was that
when the data was reorganized, or when representations were changed in 
innocuous ways, all hell broke loose - previously well-behaved applications 
now failed to work, or worse, worked but gave subtly incorrect results. It 
turned out that applications-programs had made all sorts of assumptions 
about the data, and in practice it was impossible to deduce the assumptions. 
One ended up with a giant system that did something or other, but that 
couldn't be upgraded without fear of affecting a condition that was relied 
upon by some applications-program to do its work.  Database practitioners 
thus learned the hard way that representations and data models should be 
kept separate, and that applications-programs should only talk in terms of 
data models.  

  My claim is that this sort of thing can happen again in document systems,
even though they be SGML-conformant.  I think this is the down side of 
making too much use of structure which SGML cannot validate or enforce.
I think that the very point where this becomes an important issue is when 
SGML is used to describe things that aren't just hierarchical documents,
as was suggested by Travis's posting (and by the earlier work of Rubinksy, 
of course).  

  Naturally, things don't *have* to evolve the way that I claim they will,
and it would be interesting if my claim were a self-unfulfilling prophecy. 
SGML-based document systems may take steps to avoid the problem, and some 
will argue that HyTime and other standards are intended to do just that. 
Perhaps they will; we shall see.  Steve and Eliot's proposed modifications 
to SGML, on the other hand, indicate that they think it might be worthwhile 
to extend SGML to capture more structure.  I think we have to balance such 
suggestions against Michael's observation that SGML already has too many 
bells and whistles.  And in general, I look forward to the day when the
representation and the data modelling of documents are handled separately.

-Darrell.