🚀 go-pugleaf

References:  <1992Aug4.005005.29589@news.eng.convex.com>

I think I see what you're getting at.  I guess I don't
make a distinction between declarative and structural.
Or rather, if its declarative, it must also be structural,
and then the only question is how useful is your declaration.
Said another way, is there any useful difference between
these two:

.*-- Begin italic font
.bf italic
This is italic
.*-- restore previous font
.pf

and

<italic>this is italic</italic>

I would suggest that there is no useful difference, and that
the use of SGML in the second case buys you little, if anything.

In other words, why use declarative markup if you are not also
going to use it to do more than a procedural formatting
language already did?

You say:

> The purpose of my article is to point out that SGML takes
> a stand on the procedural/descriptive distinction, but leaves
> the format/structure distinction to the application. i.e.
> it's possible to construct an SGML formatting system, but it
> will be a descriptive markup system nontheless.

It will be descriptive only to the degree that SGML is by
definition descriptive, but an ITALIC tag isn't any more
descriptive, really, than ".bf italic".  In other words,
making a formatting control a tag doesn't make it more
descriptive than it was as a formatting control.

I guess I see the format/structure distinction inherent in
the decision to use declarative markup in the first place.
I make the assumption that if you have chosen a declarative,
non-procedural path, that you have also chosen structure
and intent over formatting, otherwise, there would be no
advantage to making the move, and you would be just as happy
with Rich Text Format or TeX as your document source (happier
since the range of available processors that could eat your
documents directly is much greater than with SGML).
SGML doesn't have to take a stand because the issue is already
resolved by the time SGML comes into the picture.

Note that what I'm talking about here are general-purpose
documents that are human-created input to a document-processing
system, not intermediate data formats generated for
interchange between processes.  In that case, SGML may be
used purely for convenience and not because of the advantages
of declarative markup that acrue from its generality and
descriptiveness.

In other words, as input to a formatter, <italic> may be
more convenient than ".bf italic" because the formatter
gets parsing for free if it eats SGML.  We have to be careful
to make a distinction between documents in the sense of
human-created information and data passed between processes.
Both may be, by coincidence, encoded in SGML, but the reasons
for choosing SGML in each case are as different as the uses to which the
data is put.  When I talk about SGML documents and intent and
quote good markup design unquote I mean the former.

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