🚀 go-pugleaf

We're all of the same side here, right?  Those who feel troff is the
ultimate document representtion have already packed up and gone home.
It should therefore be possible to suggest that maybe SGML can't do
*everything* perfectly, without being considered the opposition.

The *possibility* of encoding anything in SGML is irrelevant.
It's very, very easy to design a language with that property.
I trust we all learned in high school that a theory that could
not be proven false/inadequate by any conceivable later data,
is therefore useless.  The question is not total power, but grace, elegance,
and usability.  In these areas SGML is optimized for some things, not all.

Now to specifics:

The overlapping markup case is perfectly well-defined, can be managed under
more sophisticated data models, and ***arises often in real documents***.
Data adapted from an actual SGML document prepared by the Brown University
Women Writer's Project:

   <speech speaker='Sir John'>
   <poetry-line>Greetings, O brave defender of our right,</poetry-line>
   <poetry-line>'Till now, I thought you knew not how to Write</poetry-line>
   <poetry-line>but heavy Morals.
                </speech>
                <speech speaker='Melissa'>
				      These my Pens imploy</poetry-line>
   <poetry-line>for all my business was to pall Your Joy:</poetry-line>
   ...
   </speech>

Read it aloud to see the scansion -- Two speakers divide a poetry line 
between them.  Both the speakers and the lines must be marked, because
both are structurally significant.  The above fragment isn't SGML.
Petri nets have some helpful properties for representing this sort of thing,
but I'm not fluent enough to say much more (see various articles by R. Furuta).

CONCUR could do this case (if there were more than one parser in the world
that supported it).  However, there are cases where CONCUR is inadequate,
such as Greek drama where occasionally the chorus and another speaker
speak in unison for a slight overlap within one or a few verse lines or
portions, or any case where instances of the same element type overlap.

Such overlaps are easy to *notate* in SGML, but none of those
ways helps; that is, they don't contribute positively to grace,
elegance, or usability, or permit validation of such structures (an
application can, but that's not SGML).

   <speech speaker='Sir John'>
   ...
   <poetry-line>Greetings, O brave defender of our right,</poetry-line>
   <poetry-line>'Till now, I thought you knew not how to Write</poetry-line>
   <poetry-line id=p1 continued.in=p2>but heavy Morals.</poetry-line>
   </speech>
   <speech speaker='Melissa'>
   <poetry-line id=p2 continued.from=p1>These my Pens imploy</poetry-line>
   <poetry-line>for all my business was to pall Your Joy:</poetry-line>
   ...
   </speech>

Unless Elliot has a much better solution, I think he owes Darrell the beer.

Steve DeRose