summaryrefslogtreecommitdiff
path: root/info/digests/texline/no8/more.sgm
blob: 525ecb3d97b14c9f3258d43665d94fef63c99760 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108

\centerline{\bf More SGML}
\medskip
\noindent
The \sgml\ Users Group has regular meetings,
often held at the British Standards Institute in
London. This is a rather pleasant venue, since the
building in Green Street (just off Park Lane) is rather
old, with all sorts of fancy ceilings
and ornamentation --- just the thing to distract and
amuse. The Users Group meetings are (to my mind) rather
sparsely attended (usually no more than 20--30), but it
is always fascinating to see what \sgml\ is up to. I want
to comment on presentations made at two  meetings: one held
on September 12th, and  the other held on December
2nd. 

The relevant paper at the earlier meeting was from Eric
van Herwijnen of the Data Handling Division at {\sc
cern}, Geneva. He was concerned with promoting
the use of \sgml\ in an environment which
boasted a wide range of computing equipment,
from personal machines through Suns and VAXes to
Crays. He presented a checklist which was designed to
help identify those documents which ought to be coded in
\sgml:
\item{$\bullet$}will the document be kept after it has been
read?
\item{$\bullet$}will the document be updated later?
\item{$\bullet$}does the document have a complicated
structure?
\item{$\bullet$}is the document longer than a few
pages? 
\item{$\bullet$}will the document be added to a
database? 
\item{$\bullet$}does the document have to follow the
{\sc cern} house style?
\item{$\bullet$}does the user already know \sgml\ or an
existing \sgml\ tool?

\noindent A positive answer to any of these questions
indicated that \sgml\ ought to be given serious
consideration. The alert and observant will be saying
`Why not use \LaTeX\ instead?' Eric had a response: he
considered that \sgml\ had the following advantages over
\LaTeX
\item{$\bullet$}\sgml\ is an {\sc iso} standard, while \LaTeX\
is not.
\item{$\bullet$}{\sc cern} will register its DTD (Document
Type Definition) in accordance with the ISO rules.
\item{$\bullet$}input systems for \sgml\ are becoming
available (Author/Editor, {\sc mark-it}, Publisher,
Grife). 
\item{$\bullet$}\sgml\ is being adopted by the
publishing world.
\item{$\bullet$}\sgml\ is suited to document database
applications.
\item{$\bullet$}\sgml\ support is easier.
\item{$\bullet$}\sgml\ has been chosen by Eric's department
for the future office system at {\sc cern}.

\noindent It wasn't clear to me why \sgml\ was the
obvious candidate, but it is obvious that systems which
have the label `standard', and which have some sort of
economic or commercial clout behind them appear more
attractive to large organisations. 

The other paper was from Paul Ellison at Exeter
University, who discussed how maths could be handled in
\sgml{}. As I have noted elsewhere, \sgml\ usually opts out
of maths, and leaves it up to some competent system to
handle. Usually this is either |eqn| or \TeX{}. Paul
showed how maths could be coded in \sgml{}.  One of the
\sgml-based criticisms of \TeX\ is the way it handles
superscripts and powers: how do you distinguish between
|x^2| where the 2 is a power, and |x^2| where the 2 is a
superscript. Well, the short answer is that no
mathematician in his right mind would use such ambiguous
notation. Of course there is an
easy solution to this. There is no reason why |\sp|
shouldn't mean `superscript' and |^| mean `power'. Try
writing |\sp| sometime and see what it does. Paul had
confused a |plain|\TeX\ facility with a coincidence of
expression. But it is a point which Knuth treats
ambiguously too --- but hardly a reason to discard \TeX!
In his examples of \sgml\ coding Paul also tackled the
problem of `pre-scripts' like $_nx$, which have to be
handled in a rather awkward, although very explicit, way.
I have never been too happy with the \TeX\ coding here,
since eventually you end up having to say things like
|_na+{}_nb| in order to guarantee the spacing of
$_na+{}_nb$. The |{}_nb|, if it is read as |{}_n|, followed
by |b|, is meaningless. I really cannot see \sgml\ coding
of maths catching on. With very few exceptions, \TeX\ is
unambiguous in its treatment of maths; 
a little extra exposition and discipline would have been
sufficient to remove any problem areas. The extra
pain and effort of invoking \sgml\ seems out of all
proportion.

Apart from these two \TeX-relevant talks, \sgml\ User Group
meetings are also quite useful as a way of keeping in touch
with some other aspects of the `structured documentation'
world. Many of the speakers are from commercial
organisations, and it is always of interest to see how
real world problems are identified and solved. 
\smallskip
\rightline{\sl Malcolm Clark}