First of all, I want to express general (and substantially complete)
agreement with Ned's long discussion. We use a lot of SGML around here
for documents (and things that are nearly, but not quite, documents)
precisely because of the significant decoupling of "document" from
"representation" and because we can use text tools and a number of
filtering arrangements for handling SGML that can't work on page
descriptions (e.g., Postscript) or even low-ish level markup languages
(TeX, nroff,...).
That said, I think Bill makes some very useful points from which I'd
like to try to generalize a very little bit.
Q: Can one use conventional-text-SGML (Ned's and my versions) to
represent some rather complex structured things without thereby making
it "non-text"?
A: Of course, and there are lots of such applications out there.
Q: Can one make up a DTD and set of practices for using SGML that are
so layout-specific as to be (pick one) (i) lower level than TeX, (ii)
more of an "image" specification than the typical use of Postscript,
(iii) full of embedded images, (iv) totally unintelligible without
presentation through a DTD-specific application?
A: Of course one can. It requires either a modicum of intelligence
combined with lack of sensitivity (or interest) in why one might not
want to do that or a small excess of general stupidity.
Q: Can one use a subset of Postscript in a way that would permit it to
be treated as a markup language for free text.
A: Yes, and the "header only" stories are clearly one way.
Q: Can one use Postscript in a way that is sufficiently instruction-
laden and layout specific as to make it non-revisable and useless
without a display application (e.g., a properly equipped printer)?
A: yes, pretty easily.
My--frightfully dangerous--inference....
text-plus/SMGL and probably (like Ned, I'm still a bit skeptical)
text-plus/Postscript
are valid combinations. So are
application/SGML and application/Postscript
And the difference is a matter of use and intent, not of whether "SGML"
is inherently "text-plus" or "application". It seems to me that the
intent is important here, and this provides a way to express that
intent, i.e., that it is reasonable to register both pairs of
combinations, with appropriate guidance about use.
The concept Ned has in mind when he discusses the kind or use of SGML
(or, as Bill correctly points out, the family of DTDs) that he sees as
text-plus seems pretty clear to me. And we can all make examples that
would be "application" at best. Similar remarks probably apply to many
of the other obvious text-plus categories, as well as to sliding some
Postscript texts into that category.
If the concept and distinctions are to be useful, then one must hope
that the originating user or sending system know, and hope that they
will accurately reflect whatever we believe. If that is not possible,
then we may have too many top-level types and should look at
"displayable on character device", "displayable on bitmapped device",
and maybe a few categories of "other"/"not intended to be displayed" and
be done with it.
Maybe that is all we should expect, and the putative problem
here does not need solving.
--john