This document describes the content of the components of Rob Beezer's
FCLA book, as described in

http://aimath.org/~farmer/print/fcla_structure.pdf

I try to use the terms "block" and "component" as technical terms,
as in the "structure" document.

There are three types of components: acronyms, titles, and text.

1. Acronyms

Rob attaches an acronym to most of the blocks in his book.
For example, section
    Matrix Inverses and Nonsingular Matrices
has acronym: MINM

Acronyms are unique within a category (Chapter, Section, Theorem, etc),
but not necessarily across categories.

Acronyms are used to reference one block from another block.  For example,
"definition UM" refers to the definition with acronym UM.

Rob has a particular syntax for referring by acronym, described below.

2. Titles

Titles are one line of text.

3. Text

Everything else is text.  Some are more specialized, such as the
statement of a definition.  Others are generic, such as the introduction to
a section.

A key issue is the markup which is can appear in text.
Items which appear in Rob's book and also must appear in any viable
authoring tool:

a) Blank line (i.e., two successive carriage returns) marks a paragraph break.
One carriage return by itself is the same as a space.  A tab is the same as a
space.

b) LaTeX markup of math.  A good baseline is MathJax: we need to allow all
the math which MathJax handles by default.

The next step is to allow user-defined macros.  As I wrote elsewhere, there
are good macros and bad macros.  We can't stop people from making macros, so
we can limit them to making good macros.  Rob has lots of good macros, for
example:  \adjoint{A}   means "the adjoint of the matrix A"

This is a good macro because it is self-explanatory (in context, at least),
and it contains useful information.  And it also separates content from
presentation, because there is more than one way to typeset "adjoint",
and the author doesn't need to worry about that.

Bad macros obscure information.  For example:  \be   may mean  "\beta",
or it may mean "\begin{equation}". 
Bad macros should be automatically expanded into their definition.

Rob has about 100 macros.  You can see them in the html source of my
version of his book, where I provide the information MathJax needs to
render most of them.  http://aimath.org/textbooks/beezer/

c) Citations and references.  You need to be able to label a block and
then refer to it.  For example:
"By equation \eqref{eqn:quadratic_formula} we find that the minimum
occurs at $x=4$."

Here we have an equation that appears somewhere in the document, that
equation is numbered in the text, and we want to refer to that equation
later.  The reference allows a link in the HTML version (although a
knowl would be better), and in print you can find the referenced
material because things are numbered.

Rob has extensive references by acronym, using the syntax
\acronymref{section}{PT}

Rob never refers to equations, only to blocks which have an acronym.
That is unusual, and we need to support authors labeling items and then
referring to them, such as with the LaTeX \label{} command.

d) Simple lists.  Occasionally one needs a simple itemized or
bulleted list.  Rob uses LaTeX syntax for this, but he doesn't really
need the infinite capabilities of LaTeX lists.  Probably Markdown
syntax would be adequate.

--------
Rob uses the following, which I am not sure should be on the "must have"
list:

e) Font-like markup.  Rob uses \define{the_word} to emphasize the term
being defined in a definition.  That syntax doesn't make sense anywhere
else.

f) Images and captions.  Rob only has 3 or 4 images and captions in the
whole book.  I had to handle these with a hack, so I don't have any
well-formulated thoughts yet.  But note that an image needs to be available
in some "source" format, so that a variety of images can be made for
different output formats.

g) Tables.  Rob only requires simple tables in a couple places.  Tables are
a complicated topic and we need to look at more actual examples.

THAT MAY BE ALL THERE IS!