🚀 go-pugleaf

Erik Naggum writes:
> It's obvious that these are issues only insofar as a document encodes
> semantics which SGML cannot enforce.  ...

I'm not aware of anything I'd call "semantics" which the SGML parser
*can* enforce, beyond guaranteeing that IDs are unique within the
document and that for each IDREF there exists a corresponding ID.  (And
these are kind of slender reeds, don't you think?)  So Erik seems to be
saying that the issues Darrell has raised are very definitely issues.

Myself, I think a markup language with better support for typed IDrefs,
with a fuller and more rational set of data types for attribute values
and for element content, would probably be stronger.  Maybe some people
will call those 'semantic', and if so, then I favor stronger semantics
for markup languages.

But most people I've talked to seem to feel that when you come down to
it, the only way to specify the 'semantics' of a thing is to specify its
processing; if this is true (and Lord knows I don't have any better
alternative, though I try to keep my hopes up), then 'semantics' are
application dependent and SGML's great superiority over all other
practical markup languages is its resolute *refusal* to provide any
mechanism whatsoever for specifying semantics (i.e. processing).
(Link type declarations appear to be intended as an exception to this
rule, but I have never understood how they could possibly work in
practice -- sorry, Charles, the Nutshell hasn't helped yet -- if anyone
has a clearer idea, please speak up.)

If 'data modeling' in general claims to define 'semantics', can someone
give some fairly concrete and simple examples of what kinds of things
data models are intended to express?  'For each EMPLOYEE there is exactly
one MANAGER'?  That kind of thing?  Not an impressive step toward
defining 'employee' is it?  Not compared to Marx and Engels, or even
Samuel Gompers.

> However, at this point, we're already out of the SGML domain.  SGML has
> done it's job, and the (SGML) application which specifies that such
> types of structure should be used, is also responsible for their use.
> This is common to large set of design problems, and I venture that the
> problem which Darrell imputes to SGML is not SGML specific at all, and
> what we see is only the relevance of a common design problem to SGML.

I don't think Darrell has ever claimed that the issues he has identified
are unique to SGML -- only that they *are* present in SGML.  This does
not, itself, constitute a criticism of SGML -- only a criticism of those
enthusiasts who claim, in their enthusiasm, that SGML does general data
modeling, or any of the other things Erik periodically points out SGML
doesn't do.  (True, he never points it out when the outrageous claims
are made, but only when someone like Darrell points out that the claims
are, in fact, a bit excessive, and then only in the form "But SGML
doesn't *do* that, and doesn't claim to!" -- why Darrell gets flamed for
pointing out, in agreement with Erik, that SGML is not a full data
modeling language, but the other guy does not get flamed for suggesting
that it is, remains one of the deeper mysteries of this newsgroup to
me.)

Why should constraints on the proper use of a given data structure be
the responsibility of the application?  In database design, that is
known as disastrous bad planning:  *all* constraints should be enforced,
wherever possible, by the dbms, not by the application program.  Leaving
it to the application program guarantees that eventually you are going
to be in a hurry and screw up in one application program, and spoil your
results.  Whenever a constraint applies to all processing of an object,
it's better to enforce it as early as possible, so the application
doesn't have to bother.  Do you feel, Erik, that this practice from DBMS
is not valid for text processing?  I think not:  you do say explicitly
that SGML is good because it validates the data, so your program doesn't
have to.  You're right.  There are times I wish it could do *more*
validation -- is that not also true for you?  Those are the places to
watch:  those are the places where we will discover useful ways to
extend or modify SGML to improve it.

> When I said above that it is not necessarily a drawback that SGML
> doesn't enforce more semantics than it does, it is because application-
> (program)-independence is not the purpose of SGML, and neither is
> portability per se (blind interchange).  The purpose of SGML is to

This sounds to me like a historical claim.  And as a historical claim,
I think it's clearly false.  If SGML was not developed to make
documents (more) device- and application-independent, then the people
on the GCA GenCode committee who worked on SGML must have been under a
strange delusion, as must Charles Goldfarb, whose paper on GML,
reprinted as Annex A of 8879, says inter alia that generalized markup
"does not restrict documents to a single application, formatting style,
or processing system" and "permits interchange between different kinds
of word processors".

It would be dumb to claim that SGML is not an improvement on most of its
predecessors, from the point of view of making documents application
independent (or application-program independent, if you insist on
replacing English with whatever language ISO uses, which is a close
relative but not quite the same thing).  And anyone who makes such a
claim needs to be straightened out, or toasted.  But I don't think
Darrell has ever made such a claim.  He has instead pointed out that the
current SGML formalism doesn't allow for the formulation or enforcement
of some imaginable types of constraints, and that in consequence any
roughly equivalent formalism will have difficulties with application
independence, because certain kinds of information are hard to transmit
in a formal way.  (English is not an optimal specification language, and
if it was designed as one, the designers should be fired.  ISO-English
is not much better.)

Darrell has in effect asked what one wants, ideally, from a tool of the
sort that most of us agree that SGML is.  I for one would really enjoy a
serious discussion of that question without constant interjections that
SGML wasn't intended to do this or that.  Particularly when the field
claimed for SGML is such a narrow one.  SGML's developers were quite
intelligent enough to design a tool with uses beyond those they had
consciously in mind.  It is no criticism of them or of SGML to say it
could be improved, and I wish Erik would stop assuming it is.

> In conclusion, I think Brian Travis' original claim stands, with the
> exception of general data modelling, and read in the context for which
> it was intended, not as an absolute edict.  I also think that Darrell's

Can you refresh my memory?  The only thing I remember Brian Travis
saying was that SGML is useful for general data modelling -- if we
except that, haven't we lost pretty much his entire claim?

I now pause to don my asbestos suit and await the inevitable replies ...

-C. M. Sperberg-McQueen
 ACH / ACL / ALLC Text Encoding Initiative
 University of Illinois at Chicago