🚀 go-pugleaf

"No, silly, SGML doesn't do point sizes and margins. It just does
headers and sections and stuff."

Well, the standard doesn't really say that, does it? I suggest that
there are two orthogonal distinctions to be made regarding markup: the
format vs. structure distinction, and the procedural vs.  descriptive
distinction. [I hope these distinctions will be edited and included
in the comp.text.sgml FAQ]

Formatting markup gives information about the physical representation
of the content: font, size, position, margins, color, (or even
speed, volume, etc. for other media).

Structural markup is an abstraction of formatting markup. It gives
information about the structure of the content, i.e. it's relationship
to the rest of the content. The HOPE (human optical processing engine)
infers the structure of a document from it's physical representation,
e.g., your eye figures out that headers are more significant than body
paragraphs becase they are set off in a larger type. Structural markup
intends to explicitly mark up these abstractions.

Procedural markup is instructions to a state machine. Implicit in most
procedural marup schemes is a machine that renders the content based
on some internal state (like a typesetter with state for font, size,
position, margins, etc.).

	Note: most modern typesetting languages (troff, TeX,
	postscript) are turing-complete state machines, which means
	that most queries on these documents ("How many characters are
	in the document?"  "Does this document contain the word
	'gamble'?")  are not computable (they belong to the class of
	problems known as "the halting problem.")

	You might say "just use grep to find 'gamble'" but the word
	might be split across two input lines joined by a continuation
	character, or the letters 'gam' might be generated by one
	macro, and the 'ble' might come from another. In the most
	general case, the queries are not computable.


Descriptive markup (should we call it declarative markup?), in
contrast, implies no particular processing engine. It uses lexical
conventions to associate properties with content. Where a procedural
markup system would say "Set italics mode.  Draw these characters. Set
roman mode," a descriptive markup system would say, "these characters
are italic."

Procedural markup has the feature/advantage/disadvantage of enclosing
processing semantics with the content. Procedural systems are often
extensible and programmable. Descriptive markup has the
feature/advantage/disadvantage of divorcing or abstracting the
semantics from the content.

SGML languages use descriptive markup by definition, and structural
markup by convention. In other words, the SGML standard places itself
in the descriptive markup camp, and leaves the format/structure
distinction up to the application. Traditional SGML applications are
structural markup systems (CALS, AAP, etc.) but some SGML applications
are in fact, formatting systems (CALS fosi stuff, DSSSL [I think]).

Dan