🚀 go-pugleaf

Darrell Raymond <drraymon@watdragon.uwaterloo.ca> writes:
|
|         SGML will result in non-portable, applications-program-dependent
|         documents.

I've been thinking about this, and relating it to a field I know much
better than data modeling.  I think the claim can be said to be largely
equivalent to the claim found in some of the strongly-typed programming
language advocacy groups:

(1)	C will result in non-portable, hardware-dependent programs.

This claim has two possible interpretations:

(1.1)	There are inherent qualities in C such that it is impossible to
	write portable and hardware-independent programs in it.

(1.2)	There are inherent qualities in C such that it is possible to
	write non-portable and hardware-dependent programs in it.

The difference between these interpretations is enormous: it's obvious
that (1.1) is false, and equally obvious that (1.2) is true.  Those who
claim (1) have invariably referred to the truth of (1.2) in defending
their claim, and then turned around and applied the conclusion as if
claim (1.1) was true.  This is, I believe, a text-book case of
"equivocation".

I see the same application of interpretations in Darrell's claim:

(2.1)	There are inherent qualities in SGML such that it is impossible
	to design portable and application-program-independent SGML
	documents.

(2.2)	There are inherent qualities in SGML such that it is possible to
	design non-portable and application-program-dependent SGML
	documents.

Claim (2.1) is obviously false, and requires no further comment.

Claim (2.2) is worth discussing, because it may be true in some senses,
and because it is not necessarily a drawback, i.e. similar to the claim
for C.

To write portable and hardware-independent programs in C, the programmer
has to employ a coding style and an overall design which caters to this
requirement.  By being very careful in not making any assumptions about
(i.e. take advantage of) the hardware representation of C objects, for
instance, portability and hardware-independence can be achieved.  To be
completely portable in C requires more than a close reading of the
standard, even though the standard clearly marks semantics which is
either "implementation-defined" and "undefined" as such.  As long as the
semantics is defined in the standard, you're safe.  As soon as you use
something which is not, and it doesn't take very special needs to do so,
the language can no longer support you.  Some programming languages
theoreticians find this exceedingly uncomfortable, to the point where
they need to lambast C for the lack of several of their favorite
features, notwithstanding C's very real contributions to the world.

While the portability issues of C are well-known, the issues Darrell
have tried to bring attention to (were it not for the provocative tone),
is whether there are such issues with SGML, where they might occur, and
what to do about them, if necessary.

It's obvious that these are issues only insofar as a document encodes
semantics which SGML cannot enforce.  It remains unclear exactly what
kind of semantics Darrell has in mind, but the main area where semantics
is entirely up to the (SGML) application is in the meaning of references
(ID/IDREF), and in the "type" of a reference, which are, indeed, types
of "structure which SGML cannot validate and enforce" (from Darrell's
article).

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.

The question should be "how do we design (SGML) applications so that we
can separate representation and data model", if this is, indeed, the
problem that Darrell's articles has tried to make us aware of.  Eliot
and Dan have offered some interesting views on this problem.  My point
is that the problem lies with the SGML application designer, and that
it's a problem regardless of whether SGML is used or not, although the
problem is probably more visible when SGML is not, because so many other
problems which would obscure this problem are cleanly solved.

We must, consequently, have a very clear idea of what we're trying to
solve, and, keep in mind that, as Jim Mason stated, SGML is an enabling
standard, which by definition limits the problem space for which it is a
solution, and which also provides a much larger problem space for which
it is a partial solution when combined with other tools.  The latter
problem space is probably not very well researched, and I react very
strongly towards any claim to the effect that "it can't be done, so give
up".  This claim has been found among the strong typing advocates in
programming language discussions, who consider classic C inferior to
their strongly-typed languages which nobody uses, because a programmer
had to use lint to take care of their pet problems.  I see it as a call
for encompassing languages and standards, partly because they are so
much simpler to deal with formally than the enabling ones, which are
intended to be tools used in a much larger setting, which it may not be
possible to capture formally.  (Hence the observation that encompassing
standards address the problem for which they were designed, while
enabling standards address the problem for which they were designed in
addition to a number of harder problems where it is applicable, but
where it may not be as well suited, however better suited than any
other, competing solution.)

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
capture the structure of information, and provide a means to describe
this structure formally, independent of any processing (semantics) it
may see.  It may be expedient to violate more globally sound rules to
accomplish a given task locally, and keeping out of the way of those who
wish to do so is more important than catering to those who have a need
to restrict things to the formally well-defined.  I would say that
reality is not formally well-defined, so if you wish to do anything
interesting, you need to have escapes out of the formal system.

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
claim that "SGML will result in non-portable and application-program-
dependent documents" is false, but that going beyond the semantics which
SGML can enforce, and using SGML as a data representation for non-
hierarchical information, imposes additional requirements on the
designer which may not be obvious to those who apply SGML to such
problems, and that if these problems are ignored, the designer must be
aware of the trade-offs involved.

Effort should be invested in what constitutes good SGML application
design, and what kind of problems we need to be aware of.  Possibly, we
can take with us some of the analysis into the revised SGML, if need be.

Best regards,
</Erik>
--
Erik Naggum             |  ISO  8879 SGML     |      +47 295 0313
                        |  ISO 10744 HyTime   |
<erik@naggum.no>        |  ISO 10646 UCS      |      Memento, terrigena.
<enag@ifi.uio.no>       |  ISO  9899 C        |      Memento, vita brevis.