🚀 go-pugleaf

Darrell Raymond <drraymon@watdragon.uwaterloo.ca> writes:
|
|   >An SGML document is, by the very definition of "SGML document" (see
|   >definition 4.282, and Chapter 4, pp 132ff), application-dependent, and
|   >it has to be.
|
|     Definition 4.282 says absolutely nothing about applications, let alone
|   that SGML documents are application-dependent.  Moreover, at least some
|   advocates of descriptive markup think they're building documents that are
|   application-independent, at least to some extent (if memory serves, the
|   Coombs et al. CACM paper claims this).

You're refusing to consider what "SGML application" means, Darrell.
This has caused most of your problems, as far as I can see.  As I said,
and as Goldfarb says in his book, and as the standard says, an SGML
document is an SGML document only with reference to a DTD, and _that_ is
part of the SGML application.  Thus, the SGML application (document type
declaration as far as the parser is concerned, but including semantics,
intended processing, etc, to the parts external to the SGML parser,
which are still part of the complete SGML system), is a sine qua non for
the SGML document.  What this means in practice is that you don't have
an SGML document if you don't have the DTD.  A mere bunch of tags does
not an SGML document make.  _This_ is what makes a given SGML document
totally and irretrievably dependent on the SGML application.  It could
not be otherwise.  What we're arguing about is the meaning of the word
"application" because you think of it as something puny, and SGML uses
the term to mean the whole sphere of questions related to applying SGML
to a given problem.

The relationship between an SGML document and the SGML application does
_not_, however, make a document dependent on an implementation of an
SGML application, and it does not make it dependent on any particular
processing, since several modes of processing could be defined by the
SGML or the text processing application.  It would be very unlikely that
a given SGML application will define low-level things like point sizes
when an element is printed, but it would naturally say something about
the information contained in the element, enough to make those who wish
to display it aware of its role in the document.

When Eliot and Steve have been discussing this, I have very strong
reasons to believe that they have used the term "application" as it is
used in SGML, while you continue to use the term as if it meant an
application _program_ (or specifications for one), as it may certainly
mean outside the SGML context.  An SGML application defines the
semantics of, and any other information external to, the markup, and
it's up to the implementor of a given application program to use this
information to build useful software.  The same is true for _any_
information representation scheme, and that is basically what SGML is.

|   >An SGML document includes a reference to (or includes) the document
|   >type declaration, which, in sufficient detail to allow parsers to
|   >process the document, defines the application.
|
|     This also seems to be wrong.  4.279 says that the application is
|   the "rules that apply SGML to a text processing application", it
|   does not say that the DTD defines the application.  In fact in the
|   notes it quite explicitly mentions several other things, such as
|   link process definitions.

Let me tell you this, Darrell: I wouldn't be irritated with you if you
had asked what something meant, instead of assuming it meant what you
think it should mean irrespective of the context in which it is used,
but you continue to make assumptions which do not hold, and you continue
to ignore the context in which SGML is defined, and you seem to have a
very strong desire to knock SGML for something which it isn't.  Instead
of listening to what people tell you, and what the standard says, and
what Goldfarb has elaborated on in his excellent book, you continue to
behave as if the only thing which is interesting in the world is whether
SGML can represent your navel.  It can't.  It wasn't meant to, and it
says so.  I don't know what keeps you going, if it isn't a desire to see
SGML keel over and die because you have found something bad about markup
in general which we should somehow regard as reverent and take to our
hearts.  You haven't given us _any_ good reason to think that markup is,
indeed, harmful, as you claim it is, but you have given us a lot of
reason to think that whatever it is you're going to say about markup,
it's not going to be terribly relevant to the tasks which markup
languages handle to the benefit of their users, and for the longevity of
information (which is my main interest in SGML, and at the heart of
SGML's utility).

Anyway, I'll try to explain what you seem to have a problem with.  Look
here, definition 4.279 says:

SGML application:
    Rules that apply SGML to a text processing application. An SGML
    application includes a formal specification of the markup constructs
    used in the application, expressed in SGML. It can also include a
    non-SGML definition of semantics, application conventions, and/or
    processing.

The "formal specification of the markup constructs used in the
application, expressed in SGML" is _precisely_ the document type
declaration.  Anybody who have read the standard and worked some with
SGML would realize this.  You imply that you have, in your line of
argumentation, but in case you haven't, see definition 4.103:

(document) type declaration:

    A markup declaration that formally specifies a portion of a document
    type definition.

    NOTE -- A document type declaration does not specify all of a
      document type definition because part of the definition, such as
      the semantics of elements and attributes, cannot be expressed in
      SGML.  In addition, the application designer might choose not to
      use SGML in every possible instance -- for example, by using a
      data content notation to delineate the structure of an element in
      preference to defining subelements.

See?  It says, right there, that the semantics cannot be expressed in
SGML.  We've known that all along.  You haven't, because you have
refused to listen.  Eliot tried to tell you, too.

What this means, in practice, is that you have to have some information
that you want to represent, and you have to have the semantics of that
information available to you somehow, but for purposes of information
representation, you choose to define a mapping between SGML constructs
and the semantics, and then represent the information with SGML
constructs.  That is, SGML allows you to represent the information which
you already know what means.  If you don't know what the information
means, you're unable to use it, anyhow.  SGML relieves you of the task
of specifying a representation for your information.

You can, however, regard the SGML document solely as an instance of a
document type and work with the element structure in SGML in an editor,
say, or in search and retrieval systems, without regard to the semantics
of the information represented.  The programs that want to do something
more than just look at the representation of the information will need
to know more about the semantics than those that don't want to do this.

|     Apart from minutiae, Erik seems to have missed the whole point of
|   the discussion between Eliot and myself.  I wanted to draw attention
|   to the fact that SGML enforces certain relationships and permits
|   arbitrary other ones outside of itself, and that the latter should
|   not be counted as "being represented in SGML" (hence the overlap
|   problem).

Why?  We already knew that.  We already knew, because we had read the
standard, and worked with SGML a little, that we come to an SGML
document with a large number of unstated semantic relationships, but the
whole point is that we express as many of them as possible in SGML (the
syntactic parts of them), and the rest in the documentation for the SGML
application.  The task of document analysis is precisely to codify what
we intuitively take for granted.  You should realize that this is very
different from other markup languages, which are primarily procedural
and intended to get something displayed on some medium.  Such is but
_one_ of SGML's uses.  Brian Travis tried to point out that there are
other uses, and you get all worked up.  SGML has been used, and continue
to be used, for the information representation task, and applications
continue to be used for the semantic analysis task.  People seem to be
happy with it, if we can judge the spread of SGML in this regard.

|   I wanted to make the further point that structure moved outside what
|   SGML can enforce is structure that is potentially application-
|   dependent (hence the claim that SGML would lead to non-portable
|   documents, non-portable because their structure may have meaning
|   only to a single application, perhaps even only a single
|   implementation).

What do you mean by "potentially application-dependent" and "perhaps
even only a single implementation", except to say that you don't
understand what an SGML application is all about?  Why do you continue
to believe that your notion of "application" and your notion of "markup"
are the right ones in the face of an astonishing amount of negative
feedback on those two counts?  You don't understand that you can't take
a document type declaration and go "Eureka!" from that alone, you don't
understand that SGML doesn't live in a void, it doesn't encompass
everything, and can't express your heart's desire.  So what?  You have
kicked up a lot of dust in this process without really saying anything
new.

Your attempt to say that the semantics that SGML can't express is
somehow non-portable, just goes to say that you wouldn't know the
documentation for an SGML system or SGML application from a gnat if it
bit you.  It is evident that you have never _seen_ an SGML application,
much less grasped enough to identify one as such if you saw it.  That
makes your arguments academic at best, and irrelevant at worst.

|   If this problem is all in my head, as Erik seems to think, then why
|   did both Steve and Eliot propose upgrades to SGML to address the
|   overlap example?  And did anyone else notice that neither of them
|   found it useful to resort to HyTime or some other standard?  It
|   makes me wonder if people are really thinking when they dismiss the
|   problems I raise by saying "SGML wasn't meant to do that, do it in
|   X".

There are things for which SGML was designed, and there are things for
which SGML wasn't designed.  This is tautologically true.  It would be
interesting to explore the range of both, but it's uninteresting to
rehash over and over again something which is already described in the
standard as not in SGML's domain.  You raise irrelevant problems,
Darrell, and you've made a hell of a lot of noise in the process.  You
have also raised a couple interesting questions, but they all but drown
in the anti-SGML noise you're making, and it's really annoying when all
you prove is that you don't understand some aspects of SGML (which is
perfectly all right), and don't want to understand it, either (which is
unforgivable).

I think both Eliot and Steve have been exceedingly patient with you, and
have taken you seriously to a far greater extent than you deserved.  I
stopped being patient with you about ten days ago, but find it necessary
to comment on your confusion because there might be people out there who
would otherwise be led to believe that you're right, and that you know
SGML well enough to make the statements you do, with the authority you
would like have, but don't.  Since you're don't even understand a basic
concept with regard to SGML's role and its scope and field of
application (see the standard, clauses 1 and 2), your authority needed
to be shot down, and your false and arbitrary statements proven to what
they are.

If you can stop making so much noise about the semantic relationships
and stop confusing "SGML application" with whatever preconceived notion
you have of it, we might be able to return to the points you had which
were relevant and interesting.  So far, you've merely done a lot to
destroy your credibility (at least with me), and made it excessively
boring to reply to you, were it not for the fact that it must be done.

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.