CoCalc Logo Icon
StoreFeaturesDocsShareSupportNewsAboutSign UpSign In

Real-time collaboration for Jupyter Notebooks, Linux Terminals, LaTeX, VS Code, R IDE, and more,
all in one place.

| Download

GAP 4.8.9 installation with standard packages -- copy to your CoCalc project to get it

Views: 418346
1
2
1 Introduction and Example
3
4
The main purpose of the GAPDoc package is to define a file format for
5
documentation of GAP-programs and -packages (see [GAP06]). The problem is
6
that such documentation should be readable in several output formats. For
7
example it should be possible to read the documentation inside the terminal
8
in which GAP is running (a text mode) and there should be a printable
9
version in high typesetting quality (produced by some version of TeX). It is
10
also popular to view GAP's online help with a Web-browser via an
11
HTML-version of the documentation. Nowadays one can use LaTeX and standard
12
viewer programs to produce and view on the screen dvi- or pdf-files with
13
full support of internal and external hyperlinks. Certainly there will be
14
other interesting document formats and tools in this direction in the
15
future.
16
17
Our aim is to find a format for writing the documentation which allows a
18
relatively easy translation into the output formats just mentioned and which
19
hopefully makes it easy to translate to future output formats as well.
20
21
To make documentation written in the GAPDoc format directly usable, we also
22
provide a set of programs, called converters, which produce text-,
23
hyperlinked LaTeX- and HTML-output versions of a GAPDoc document. These
24
programs are developed by the first named author. They run completely inside
25
GAP, i.e., no external programs are needed. You only need latex and pdflatex
26
to process the LaTeX output. These programs are described in Chapter 5.
27
28
29
1.1 XML
30
31
The definition of the GAPDoc format uses XML, the eXtendible Markup
32
Language. This is a standard (defined by the W3C consortium, see
33
http://www.w3c.org) which lays down a syntax for adding markup to a document
34
or to some data. It allows to define document structures via introducing
35
markup elements and certain relations between them. This is done in a
36
document type definition. The file gapdoc.dtd contains such a document type
37
definition and is the central part of the GAPDoc package.
38
39
The easiest way for getting a good idea about this is probably to look at an
40
example. The Appendix A contains a short but complete GAPDoc document for a
41
fictitious share package. In the next section we will go through this
42
document, explain basic facts about XML and the GAPDoc document type, and
43
give pointers to more details in later parts of this documentation.
44
45
In the last Section 1.3 of this introductory chapter we try to answer some
46
general questions about the decisions which lead to the GAPDoc package.
47
48
49
1.2 A complete example
50
51
In this section we recall the lines from the example document in Appendix A
52
and give some explanations.
53
54
 from 3k+1.xml 
55
<?xml version="1.0" encoding="UTF-8"?> 
56

57
58
This line just tells a human reader and computer programs that the file is a
59
document with XML markup and that the text is encoded in the UTF-8 character
60
set (other common encodings are ASCII or ISO-8895-X encodings).
61
62
 from 3k+1.xml 
63
<!-- A complete "fake package" documentation 
64
-->
65

66
67
Everything in a XML file between <!-- and --> is a comment and not part of
68
the document content.
69
70
 from 3k+1.xml 
71
<!DOCTYPE Book SYSTEM "gapdoc.dtd">
72

73
74
This line says that the document contains markup which is defined in the
75
system file gapdoc.dtd and that the markup obeys certain rules defined in
76
that file (the ending dtd means document type definition). It further says
77
that the actual content of the document consists of an element with name
78
Book. And we can really see that the remaining part of the file is enclosed
79
as follows:
80
81
 from 3k+1.xml 
82
<Book Name="3k+1">
83
 [...] (content omitted)
84
</Book>
85

86
87
This demonstrates the basics of the markup in XML. This part of the document
88
is an element. It consists of the start tag <Book Name="3k+1">, the element
89
content and the end tag </Book> (end tags always start with </). This
90
element also has an attribute Name whose value is 3k+1.
91
92
If you know HTML, this will look familiar to you. But there are some
93
important differences: The element name Book and attribute name Name are
94
case sensitive. The value of an attribute must always be enclosed in quotes.
95
In XML every element has a start and end tag (which can be combined for
96
elements defined as empty, see for example <TableOfContents/> below).
97
98
If you know LaTeX, you are familiar with quite different types of markup,
99
for example: The equivalent of the Book element in LaTeX is \begin{document}
100
... \end{document}. The sectioning in LaTeX is not done by explicit start
101
and end markup, but implicitly via heading commands like \section. Other
102
markup is done by using braces {} and putting some commands inside. And for
103
mathematical formulae one can use the $ for the start and the end of the
104
markup. In XML all markup looks similar to that of the Book element.
105
106
The content of the book starts with a title page.
107
108
 from 3k+1.xml 
109
<TitlePage>
110
 <Title>The <Package>ThreeKPlusOne</Package> Package</Title>
111
 <Version>Version 42</Version>
112
 <Author>Dummy Authör
113
 <Email>[email protected]</Email>
114
 </Author>
115

116
 <Copyright>&copyright; 2000 The Author. <P/>
117
 You can do with this package what you want.<P/> Really.
118
 </Copyright>
119
</TitlePage>
120

121
122
The content of the TitlePage element consists again of elements. In
123
Chapter 3 we describe which elements are allowed within a TitlePage and that
124
their ordering is prescribed in this case. In the (stupid) name of the
125
author you see that a German umlaut is used directly (in ISO-latin1
126
encoding).
127
128
Contrary to LaTeX- or HTML-files this markup does not say anything about the
129
actual layout of the title page in any output version of the document. It
130
just adds information about the meaning of pieces of text.
131
132
Within the Copyright element there are two more things to learn about XML
133
markup. The <P/> is a complete element. It is a combined start and end tag.
134
This shortcut is allowed for elements which are defined to be always empty,
135
i.e., to have no content. You may have already guessed that <P/> is used as
136
a paragraph separator. Note that empty lines do not separate paragraphs
137
(contrary to LaTeX).
138
139
The other construct we see here is &copyright;. This is an example of an
140
entity in XML and is a macro for some substitution text. Here we use an
141
entity as a shortcut for a complicated expression which makes it possible
142
that the term copyright is printed as some text like (C) in text terminal
143
output and as a copyright character in other output formats. In GAPDoc we
144
predefine some entities. Certain special characters must be typed via
145
entities, for example <, > and & to avoid a misinterpretation as XML markup.
146
It is possible to define additional entities for your document inside the
147
<!DOCTYPE ...> declaration, see 2.2-3.
148
149
Note that elements in XML must always be properly nested, as in this
150
example. A construct like <a><b>...</a></b> is not allowed.
151
152
 from 3k+1.xml 
153
<TableOfContents/>
154

155
156
This is another example of an empty element. It just means that a table of
157
contents for the whole document should be included into any output version
158
of the document.
159
160
After this the main text of the document follows inside certain sectioning
161
elements:
162
163
 from 3k+1.xml 
164
<Body>
165
 <Chapter> <Heading>The <M>3k+1</M> Problem</Heading>
166
 <Section Label="sec:theory"> <Heading>Theory</Heading>
167
 [...] (content omitted)
168
 </Section>
169
 <Section> <Heading>Program</Heading>
170
 [...] (content omitted) 
171
 </Section>
172
 </Chapter>
173
</Body>
174

175
176
These elements are used similarly to \chapter and \section in LaTeX. But
177
note that the explicit end tags are necessary here.
178
179
The sectioning commands allow to assign an optional attribute Label. This
180
can be used for referring to a section inside the document.
181
182
The text of the first section starts as follows. The whitespace in the text
183
is unimportant and the indenting is not necessary.
184
185
 from 3k+1.xml 
186

187
 Let <M>k \in &NN;</M> be a natural number. We consider the
188
 sequence <M>n(i, k), i \in &NN;,</M> with <M>n(1, k) = k</M> and
189
 else 
190

191
192
Here we come to the interesting question how to type mathematical formulae
193
in a GAPDoc document. We did not find any alternative for writing formulae
194
in TeX syntax. (There is MATHML, but even simple formulae contain a lot of
195
markup, become quite unreadable and they are cumbersome to type. Furthermore
196
there seem to be no tools available which translate such formulae in a nice
197
way into TeX and text.) So, formulae are essentially typed as in LaTeX.
198
(Actually, it is also possible to type unicode characters of some
199
mathematical symbols directly, or via an entity like the &NN; above.) There
200
are three types of elements containing formulae: M, Math and Display. The
201
first two are for in-text formulae and the third is for displayed formulae.
202
Here M and Math are equivalent, when translating a GAPDoc document into
203
LaTeX. But they are handled differently for terminal text (and HTML) output.
204
For the content of an M-element there are defined rules for a translation
205
into well readable terminal text. More complicated formulae are in Math or
206
Display elements and they are just printed as they are typed in text output.
207
So, to make a section well readable inside a terminal window you should try
208
to put as many formulae as possible into M-elements. In our example text we
209
used the notation n(i, k) instead of n_i(k) because it is easier to read in
210
text mode. See Sections 2.2-2 and 3.9 for more details.
211
212
A few lines further on we find two non-internal references.
213
214
 from 3k+1.xml 
215
 problem, see <Cite Key="Wi98"/> or
216
 <URL>http://mathsrv.ku-eichstaett.de/MGF/homes/wirsching/</URL>
217

218
219
The first within the Cite-element is the citation of a book. In GAPDoc we
220
use the widely used BibTeX database format for reference lists. This does
221
not use XML but has a well documented structure which is easy to parse. And
222
many people have collections of references readily available in this format.
223
The reference list in an output version of the document is produced with the
224
empty element
225
226
 from 3k+1.xml 
227
<Bibliography Databases="3k+1" />
228

229
230
close to the end of our example file. The attribute Databases give the
231
name(s) of the database (.bib) files which contain the references.
232
233
Putting a Web-address into an URL-element allows one to create a hyperlink
234
in output formats which allow this.
235
236
The second section of our example contains a special kind of subsection
237
defined in GAPDoc.
238
239
 from 3k+1.xml 
240
 <ManSection> 
241
 <Func Name="ThreeKPlusOneSequence" Arg="k[, max]"/>
242
 <Description>
243
 This function computes for a natural number <A>k</A> the
244
 beginning of the sequence <M>n(i, k)</M> defined in section
245
 <Ref Sect="sec:theory"/>. The sequence stops at the first
246
 <M>1</M> or at <M>n(<A>max</A>, k)</M>, if <A>max</A> is
247
 given.
248
<Example>
249
gap> ThreeKPlusOneSequence(101);
250
"Sorry, not yet implemented. Wait for Version 84 of the package"
251
</Example>
252
 </Description>
253
 </ManSection>
254

255
256
A ManSection contains the description of some function, operation, method,
257
filter and so on. The Func-element describes the name of a function (there
258
are also similar elements Oper, Meth, Filt and so on) and names for its
259
arguments, optional arguments enclosed in square brackets. See Section 3.4
260
for more details.
261
262
In the Description we write the argument names as A-elements. A good
263
description of a function should usually contain an example of its use. For
264
this there are some verbatim-like elements in GAPDoc, like Example above
265
(here, clearly, whitespace matters which causes a slightly strange
266
indenting).
267
268
The text contains an internal reference to the first section via the
269
explicitly defined label sec:theory.
270
271
The first section also contains a Ref-element which refers to the function
272
described here. Note that there is no explicit label for such a reference.
273
The pair <Func Name="ThreeKPlusOneSequence" Arg="k[, max]"/> and <Ref
274
Func="ThreeKPlusOneSequence"/> does the cross referencing (and hyperlinking
275
if possible) implicitly via the name of the function.
276
277
Here is one further element from our example document which we want to
278
explain.
279
280
 from 3k+1.xml 
281
<TheIndex/>
282

283
284
This is again an empty element which just says that an output version of the
285
document should contain an index. Many entries for the index are generated
286
automatically because the Func and similar elements implicitly produce such
287
entries. It is also possible to include explicit additional entries in the
288
index.
289
290
291
1.3 Some questions
292
293
Are those XML files too ugly to read and edit?
294
Just have a look and decide yourself. The markup needs more characters
295
than most TeX or LaTeX markup. But the structure of the document is
296
easier to see. If you configure your favorite editor well, you do not
297
need more key strokes for typing the markup than in LaTeX.
298
299
Why do we not use LaTeX alone?
300
LaTeX is good for writing books. But LaTeX files are generally
301
difficult to parse and to process to other output formats like text
302
for browsing in a terminal window or HTML (or new formats which may
303
become popular in the future). GAPDoc markup is one step more abstract
304
than LaTeX insofar as it describes meaning instead of appearance of
305
text. The inner workings of LaTeX are too complicated to learn without
306
pain, which makes it difficult to overcome problems that occur
307
occasionally.
308
309
Why XML and not a newly defined markup language?
310
XML is a well defined standard that is more and more widely used. Lots
311
of people have thought about it. Years of experience with SGML went
312
into the design. It is easy to explain, easy to parse and lots of
313
tools are available, there will be more in the future.
314
315
316