🚀 go-pugleaf

Alasdair,

My analogy with the C language was not intended to be literally valid,
but to point out a similarity with respect to external semantics of
parts of the languages.

Also, you, too, seem to fail to grasp that SGML, per se, does not define
the semantics of the structures for which it does define the syntax.
Why is this so hard to understand?

Alasdair Grant <ag129@cl.cam.ac.uk> wrote:
|
|   > Claim (2.1) is obviously false, and requires no further comment.
|
|   It at least requires a definition of `portable'.  Any SGML document
|   can be broken down into its syntactic fragments, but does that make
|   it portable?  If you were sent a program in a new language, a BNF
|   grammar would let you _see the structure_, but you would not
|   _understand what it meant_.

So?  The SGML document type definition defines the semantics, of which
the document type declaration is the formal specification of the
language.  How the DTD defines the semantics is not part of ISO 8879
SGML.  This is exactly as in language definitions elsewhere, where you
have one part of the definition of the language, more formal than the
other, which defines the grammar, and one part which defines the
semantics.  SGML takes care of the syntactic and representational parts
of a markup language definition, both for the abstract language, and for
the concrete syntax.  The semantics is defined in a more prose-like
manner, in the complete document type definition.

|   I think Darrell's point is
|
|   "In practice, SGML does not sufficiently address the problems of
|   document portability _between applications_."

No.  Well, I certainly won't speak for Darrell, but there is no issue of
a portability problem for SGML documents.  There's _perhaps_ an issue of
proper specifications for semantic in the SGML application so that
application programs can be written from them, and thus, portability or
(perhaps more properly) implementability _of_ SGML applications is the
key.  Application-programs that purport to implement the semantics of an
SGML application and that won't produce the same result (according to
the specification), either has bugs, or point out deficiencies in the
specification of the SGML application.  Neither of which can possibly be
a problem with SGML, per se.  It's just a fact of life that you have to
supply the semantics in a different language than you supply the
grammar, as is done everywhere else.

Thus, this issue is not related to SGML.  It's related to problems with
formal specification of semantics.  It surfaces with SGML, too, because
SGML relies on the specification of semantics external to the SGML
document as such.

The problem that has been raised should perhaps be rephrased as "What
constitutes a good specification of semantics in an SGML application",
and we can proceed to find solutions to this problem.

SGML wasn't designed to be the encompassing standard some would like it
to be, and attack it for not being.  It's a tool, intended to solve one
part of a set of problems faced by information users.  If you complain
that it doesn't solve all your problems, I can think of two reasons for
this:

1.  SGML is so good at doing its job that people wish it would do more,
    and complain when it doesn't, or
2.  those who complain don't know what it was intended to do, and/or
    what it does.

SGML was not intended to be alone in this world, and consequently, it
does not attempt to do everything, and something else must attend to
other parts of a complete solution.

|   So proprietary document types, which have no meaning to general
|   document-processing applications, will not go away.

You're seriously mistaken if you believe that an SGML document has "no
meaning to general document-processing applications".  Where have you
been while this thread has been going on?  Some relationships and the
syntax for representing them are certainly defined in SGML.  You can
work on these relationships and on the element and entity structures
with any syntax-driven tool.  Such tools include editors, and index,
search and retrieval engines, among the obvious.

I wish more people would take a little time to study what SGML can do,
and see what part of a solution it does solve, because this part is very
significant in real problems.  There are things we can do better, and
perhaps strong typing of ID/IDREF is one way to go, but adding more
semantics to the specifications is not among them, since SGML is
intended to be a information representation vehicle, to be given
semantics according to the needs of the user.  I see this as a strength,
not a problem.  Perhaps it's because I have played with SGML for some
time, and find that it can relieve me of many problems.  Foremost among
them is the ability to validate input prior to use.

I think there's a need to write something on SGML's expressive power,
and which domains it can talk about.  Perhaps something is needed to
talk about the non-hierarchical structures that ID/IDREF attribute
values may represent.  Personally, I think HyTime attends to that
problem pretty well, but HyTime is harder to understand than SGML is,
and perhaps this needs elucidation.

Sorry about the length and redundancy in this piece.  I don't have the
time to edit it properly.

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.