But the biggest problem we face, I think, is that we need a clear
formulation of a formal model for SGML. If we get such a formal model,
we will be able to improve the strength of SGML in several ways.
We commonly think of SGML documents as data objects, to be processed
by our programs. I ask you now to participate for a moment in a thought
experiment: what would the world be like, if our SGML documents were
not documents, but programs? Our current programs for processing SGML
documents would be compilers or interpreters for executing SGML
Well, first of all, we discover a tremendous gap: we have lost
everything we used to know about programming language semantics, and we
have no serious way of talking about the meanings of these SGML
programs. And for that matter, we have no serious way of talking
about what happens when we compile or execute them. In other words, we
have made our programs reusable (we can run the same program / document
with different compilers) and so we can use just one programming
language instead of many, and this is good, but it would be nice to have
a clue about the semantics of the interpretations our compilers make of
the language we are using.
The clearest analogy I can think of to our situation is that in SGML
we are using a language like Prolog, in which each program (document)
has both a declarative interpretation and an imperative or procedural
interpretation. If you ignore the procedural aspects of Prolog
programs, you can reason about them as declarative structures; if you
attend to the procedural aspects, you can see what is going to happen
when you run the program.
The difference between Prolog and SGML is that Prolog has very
straightforward semantics for both the declarative and the procedural
interpretations, for which formal specifications are possible. In SGML,
we have a very clear informal idea of the declarative meaning of the
document, but not a very formal one. And we have no vocabulary except
natural languages for talking about processing them.
Ironically, it is not easy to say exactly what ought to be meant by
the term semantics. Different people use it in different
ways, and if it does have a specific, consistently used meaning in
formal language studies, then the practitioners have kept it a pretty
well guarded secret. So I can't tell you what semantics
means; I can only tell you what I mean by it today.
Imagine I am about to send you an SGML document. Included in this
document are two elements I suspect you may not have encountered before:
blort and vuggy. When I say I'd like to have a good
specification of their semantics, I mean I would like to be able to tell
you, in a useful way, what blort and vuggy mean, and
what formal constraints are implied by that meaning.
But we don't seem to know how to do that.
The prose documentation, if there is any and if I remember to send
it, may say what a blort is, or it may not. It may tell you
what vuggy means, but if it does it may say only “full of
vugs; the attribute TRUE takes the values YES, NO, or UNDETERMINED”.
Unless you are a geologist you probably don't know what a
vug is, and if you are a geologist you may harbor some
justifiable skepticism as to whether I know and am using the term
Even if my prose documentation does explain that a vug
is an airhole in volcanic rock, and you know how to decide how many vugs
make a rock vuggy, I have probably not succeeded in specifying what
follows logically from that meaning in any useful way --- probably not,
that is, in a way that a human reader will understand and almost
certainly not in a way that a validating application can understand and
act upon. For example, how many people here realize, given our
definition of vuggy
, that the tag <vuggy true=yes>
incompatible with the tag <rock type=metamorphic>
--- since the
definition of a vug is that it's an airhole in volcanic, i.e. igneous,
rock. If you noticed that, congratulations. Are you right? I don't
know: if some vuggy igneous rock is metamorphosed and the airholes are
still there, is it still vuggy? I don't know: I'm not a geologist, I'm
just a programmer. Is there a geologist in the house?[4
It would be nice to be able to infer, from the formal definition of
vuggy, whether or not <vuggy true=yes> is incompatible
with <rock type=metamorphic>, just as we can infer, from the
DTD, that <vuggy true='76.93%'> is not valid, since the
attribute true can only take the values YES, NO, and
UNDETERMINED. Prose is not a guaranteed way of being able to do that.
So what can we manage to do by way of specifying the
‘semantics’ of blort and vuggy? We
don't seem to know how to specify meaning in any completely satisfactory
way. What do we know how to do? Well, we can fake it. Or to put it in
a more positive light, we can attempt to get closer to a satisfactory
specification of meaning in several ways:
4.2.1. Prose Specification
First, we can attempt to specify the meaning in prose.
Specifications in prose are of course what most of our manuals
provide in practice. It is handy to formalize this as far as possible,
to ensure consistent documentation of all the characteristics of the
markup that we are documenting. We've heard obliquely about a number of
systems people use to generate structured documentation of SGML tag
sets: Yuri Rubinsky mentioned one used internally by SoftQuad; Debby
Lapeyre mentioned one; the Text Encoding Initiative (TEI) uses one; I am
sure others exist too. This is already a live issue. And it will
continue to occupy our attention in the coming years.
Natural-language prose is, at present, the only method I know of for
specifying “what something means” in a way that is intuitive to
human readers. Until our colleagues in artificial intelligence make
more progress, however, prose specifications cannot be processed
automatically in useful ways.
Second, we can define synonymic relationships, which specify that if
one synonym is substituted for another, the meaning of the element,
whatever that meaning is, remains unchanged. If we didn't know in
advance what blort and farble type=green meant, we
probably still don't know after being told they are synonyms. But
knowing we can substitute one for the other while retaining the meaning
unchanged is nevertheless comforting.
4.2.3. Class Relationships
Third, we can define class relationships, with inheritance of class
properties. It doesn't tell us everything we might need to know, but if
we know that a blort is a kind of glossary list, or a kind of
marginal note, we would have some useful information, which among other
things would allow us to specify fall-back processing rules for
applications which haven't heard of blorts but do know how to
process marginal notes.
The fact that HyTime found it useful to invent the notion of
architectural form, the fact that the TEI has found it
useful to invent a simple class system for inheritance of attribute
definitions and content-model properties, both suggest that a
class-based inheritance mechanism is an important topic of further work.
4.2.4. License or Forbid Operations
Fourth, we can define rules that license or forbid particular
relations upon particular objects or types of objects. We may not know
what a blort is, but we can know that it stands in relation X
to the element granfalloon, and we can know that no
blort can ever stand in relation Y to any element of type
In addition to relations, we can specify what operations can be
applied to something: knowing that INTEGER objects can be added while
DATE objects cannot, especially if one of the DATE objects is “in the
reign of Nero”, is part of what we mean when we say we understand
integers and dates.
An ability to define legal operations for SGML objects is a key
requirement for using SGML in data modeling.
The definition of a data type involves both the specification of the
domain of values it can take on and the spec of operations which can
apply to it. Because SGML has no procedural vocabulary it is very
difficult to imagine how to specify, in SGML, the operations applicable
to a data type. It would be useful to explore some methods of formal
specification for legal operations upon SGML objects.
But note that “what it can do” and “what can be done to
it” are not, really, specifications of “what it means”.
Moreover, object-oriented specifications cannot be exhaustive. In an
application program, if an operation P is not defined for objects of
type Q, it counts as a claim that operation P is illegal for such
objects. Even if it's not illegal, you aren't going to get anywhere by
trying to call it, so it might as well be illegal. In SGML, with our
commitment to application independence, that isn't the case. If no
definition of addition for DATE objects is provided, that could mean
that it is semantically invalid: dates can never be added. Or it could
mean that we just haven't got around to it yet, or haven't thought about
it yet. So the absence of a method for performing an operation doesn't
tell us whether the operation is or should be legal upon a particular
type of object. Obviously, instead of leaving operations undefined, we
could specify explicitly that certain operations are illegal for objects
of a certain class. But it is not feasible to make an list of all the
things that cannot be done to DATES, or BLORTS, or GRANFALLOONS, because
the list is likely to be infinite.
Nevertheless, as a way of approaching the formal description of
applications, object oriented work is very promising. It's fairly
obvious that in the future we need to work together with those people
developing the object-oriented programming paradigm.
4.2.5. Axiomatic Semantics
Fifth, we can specify in some logical notation what claims about the
universe of our document we can make, given that it is marked up in a
certain way, and we can define what inferences can be made from those
claims. The synonymic relations I was talking about a moment ago are
just a special case of this.
Formal logic (i.e. first-order predicate calculus) certainly makes
possible the kinds of inference I've been talking about, but even
predicate calculus makes some concessions to the difficulty of the
problem. I can infer that this value for this attribute and that value
for the other one are consistent, inconsistent, etc. But since Frege
and Russell and Whitehead, logic has treated itself as a purely formal
game divorced from meaning; the only relation to the real world is by
way of models which involve assigning meanings to the
entities of the logical system and seeing which sentences of the logical
system are true under these interpretations. The problem is that
“assign a meaning in the real world to an entity or operation of the
logical system” is taken as a primitive operation and thus
effectively undefined. We all know how to do this, right? We can't
define semantics, but we know it when we see it.
In work on declarative semantics, we can learn a lot from recent
experience with logic constraint programming and declarative
programming. The declarative approach to SGML semantics has a certain
appeal, both because it fits so well with the perceived declarative
nature of SGML as it is, and because declarative information is useful.
As John McCarthy said in his Turing Award lecture,
The advantage of declarative information is one of generality.
The fact that when two objects collide they make a noise can be
used in a particular situation to make a noise, to avoid
making a noise, to explain a noise, or to explain the absence of
noise. (I guess those cars didn't collide, because while I
heard the squeal of brakes, I didn't hear a crash.)
One worry about declarative semantics is that it might prove
difficult to define processing procedures in a declarative way. But in
fact it is possible to specify procedures declaratively as Prolog, and
logic constraint languages, and the specification language Z show us.
So I think a formal, axiomatic approach of some kind is very
But let's be real: it is very unlikely from a description of the tag
set in first-order predicate calculus that you or I, let alone the
authors we are working with, will understand what a blort is,
or even what a vug is.
4.2.6. Reduction Semantics
Finally, I should mention one further method of formal semantic
specification: reduction semantics. Reduction works the way
high-school algebra works. One expression (e.g. “(1 + 2) + 5” is
semantically equivalent to that expression (“3 + 5”), that one to
this other one(“8”), and so on. If you work consistently toward
simpler expressions, you can solve for the value of X. There has been
substantial work done on reduction semantics in programming languages,
including LISP and more purely functional languages like ML.
Moreover, reduction semantics doesn't have to be defined in terms of
string expressions: it is entirely possible to define reduction
semantics in terms of trees and operations upon trees.
Take a simple example: if we have an element A
content model is “B+”, does the order of B
s matter? In
SGML there is no way of saying yes or no. Reduction semantics allows
you to say that this tree (gesture)
<a><b>Apples ... </b><b>Oranges ... </b></a>
is the same as that tree (gesture)
<a><b>Oranges ... </b><b>Apples ... </b></a>
so sequence is not important. Or that they are not the same, so
sequence is significant.
We have a good example of this type of work in the paper
“Mind Your Grammar” and the
grammar-based DB work at the university of Waterloo by Frank Tompa and
I think this is a very important field for further work.
In summary: we have at least six areas to explore in trying to work
on better semantic specification for SGML: structured documentation
(the kind of thing SGML itself is good at), synonymy, classes, operation
definitions, axiomatic semantics, and reduction semantics.
I don't know whether these activities would constitute the
specification of a semantics for SGML and for our applications, or only
a substitute for such a specification, in the face of the fact that we
don't really know how to say what things mean. Certainly no
lexicographer, no historical linguist, would feel they constituted an
adequate account of the meaning of anything. And yet I suspect that
these activities all represent promising fields of activity.