🚀 go-pugleaf

There needs to be a bit of clarification about the roles of DSSSL and
other means of attaching processing semantics to SGML documents. Some of
the mechanisms (notably the CALS FOSI) are relatiely limited means of
attaching a particular class of semantics to an SGML document. In the
case of the FOSI, the semantics are of more-or-less traditional
typesetting language. Such a language may use SGML as its means of
expression, but it brings along the semantic mindset of typesetting.
The FOSI was never meant to be more than that and was developed only as
a stopgap until more sophisticated tools could be developed. DSSSL and
HyTime, in contrast, are more generalized tools for attaching other
kinds of semantics (there are, of course, some commercial products that
do similar things, but I'd rather keep commercialism out of the
discussion). 

DSSSL and HyTime partially complementary, partially overlapping
approaches to attaching semantics. HyTime evolved from an attmpt to deal
with some of the semantics of music (and an application for that
purpose, the Standard Music Description Language, SMDL, remains at CD
level in ISO/IEC JTC1/SC18/WG8 pending the completion of HyTime 
this summer). HyTime's inclination can be deduced from its provision
measurements in finite coordinate spaces (which include, potentially,
both time and space). DSSSL had an early inclination towards typography
(one reason for the unfortunate name imposed upon it), but it has become
a much more generalized tool whose purpose is the transformation of SGML
documents. The DIS text of DSSSL includes one semantic specific
processor (a DSSSL term) for formatting because such was required by the
scope of the standard, but provision is made for additional SSPs that
may not have anything to do with formatting.

The recent discussion of the semantics of SGML applications and the
relative portability of such applications should be formally grounded in
the words of the standards. However, it is useful to understand the
philosopy of the developers of the standards because we have not always
done a perfect job of capturing our intentions in formalisms. Sometimes
we have followed our standards with supplementary (and nonnormative)
materials, such as CFG's SGML Handbook. In the case of HyTime, however,
we have made an explicit statement in the Scope clause that we are
developing "an enabling standard, not an encompassing one". That
statement could be applied to SGML and DSSSL as well. By it we mean that
we are developing tools from which others who come after us can build
applications which we have not ourselves foreseen. Philosophically that
is similar to the approach of the old UNIX shell builders who, not
knowing what future users would do with the shell, created a set of
tools from which applications could be built.

Our approach differs from that of builders of encompassing standards,
such as ODA, who have built meta-applications with embedded semantics.
Those standards are intended to meet one set of goals (blind interchange
was supposedly one of them, though it sometimes seems elusive). Long
ago, when most of us were coming out of a background in markup languages
of the sorts implied by the macro packages attached to troff and Tex, we
also considered codifying semantics. The "System X" project (no
relationship to any GUI) that was one of the ancestors of SGML included
a vast list of document elements (with implied semantics). But we soon
realized that the list was endless and that semantics could be argued
even more interminably (one user's "chapter" is another's "para0"), and
we turned our attention to developing a tool for capturing
relationships, with the semantics left to a later day. Having developed
that tool, SGML, we are now developing others, DSSSL and HyTime. Some
semantics are also being specified in DSSSL and SMDL, but we still
intend to remain largely toolmakers, not semanticists. 

The present discussion in this conference has been heated at times and
even occasionally instructive. Our tools are not things to be taken at
face value, neither are they appropriate objects of religious
veneration. When I got in on the discussion, it seemed to be a response
to Brian Travis's "Tag" article. I don't take that article to be the
throwing down of a gauntlet that some seem to have wanted to make it.
Instead I see in Brian's assertion the rather awestruck observation of
someone who has been around SGML since the early days that our creation
has been applied to things we never imagined a decade or so again. To me
that is a confirmation of our decision to become toolmakers--a decision
We stand by even as we try to build new tools and improve old ones.

James David Mason
Convenor, ISO/IEC JTC1/SC18/WG8
masonjd@ornl.gov


C
C
C
documents. The DIS text of DSSSL includes, because 




programs like troff and TeX.