First, we can ignore sections in the SYNTAX
which merely provide an organization
for human readers. They can be referred to in other documents
but then they become another piece of documentation. Similarly for the comments
that make a piece of documentation user friendly.

.Road_works_ahead
A typical comment
defines a structured object and its components can be refered to in
a syntax (inspired by HyperTalk) like this with subscripts:

I assume that all comments are removed and some abbreviations are expanded
so that we only have to define the meaning of a collection of simple
declarations ( variable::type ), simple definitions ( `variable::type=
expressions` ), and well-formed formulae ( axioms and theorems). Further
multiple declarations have also been resolved so that for each symbol and
type there is no more than a single declaration and/or definition - hence
we can model the documentation as a collection of sets of declarations.
definitions, and formula.

Documentation defines the classes of objects that fit. Documentation
defines the structure or type of the objects - the components must be the
variables of the documentation (the signature of Z, Σ.Algebras,
S-Algebras). Each object must also fit the wffs asserted in the
documentation - this defines the class of the documentation. The added
constraint is the conjunction of (1) the axioms and (2) defined terms:

So, the simplest theory of a piece of documentation is that documentation s is reducible to a schema form like this:

constraint(s)::=for some declare_defined(s) ( and (assertions(s)) ) where

declare_defined(s):= List{ t:T || (t,T,e):definitions(s) }.

A more complex model separates out a part of the document in this form:

given(s)::= [ variables(s) ] (and( assumed(s)) ).
Then the given(s) describes the circumstances in which the document can used, and complete(s) describes what must follow. In logical terms suppose we have the given: [x](G(x)) and the complete: [x, y](C(x,y)) then we have this meta-theorem and derivation rule:

A simple piece of documentation has no definitions or axioms (and so no theorems):

simple(s)::@=no axioms(s).
Notice that any piece of documentation has a basic document embedded in it.

A basic piece of documentation has no theorems or definitions:

basic(s)::@=no theorems(s) and no definitions(s).
A basic piece of documentation has the property that an axiom can be removed from it with out invalidating it. In some pieces of documentation we can replace their definitions by axioms and remove their theorems and so get an equivalent but basic piece of documentation. Clearly,

Valid documentation is consistent, its variables are declared or defined,
and all theorems are provable by assuming the axioms:

valid(s)::=(consistent(s) and (freevars(s) ==> terms(s) | variables(s)) and for all t:theorems(s)(if &(axioms(s)) then t ) ).

Church's Theorem means that proofs can not be automatically constructed.
However if a putative proof has been written then
it can be verified automatically by comparing with
the rules of logic
[ logic_2_Proofs.html ]

Notice that adding a definition or declaration to a consistent valid pece
of documentation generates another valid piece of documentation - when ever
the definition uses terms that are already defined and the defined term or
declared variable is not used in the original documentation.

Note: these are not examples of good style. The identifiers
are deliberately abstract. Realistic documentation gives more clues to the
system being described. They also omit some type definitions for sets like
A, B, and C. Finally, they don't provide any example objects that can be proven
to fit the nets.

Special characters are defined in
[ intro_characters.html ]
that also outlines the syntax of expressions and a document.

Proofs follow a natural deduction style that start with
assumptions ("Let") and continue to a consequence ("Close Let")
and then discard the assumptions and deduce a conclusion. Look
here
[ Block Structure in logic_25_Proofs ]
for more on the structure and rules.

The notation also allows you to create a new network of variables
and constraints. A "Net" has a number of variables (including none) and
a number of properties (including none) that connect variables.
You can give them a name and then reuse them. The schema, formal system,
or an elementary piece of documentation starts with "Net" and finishes "End of Net".
For more, see
[ notn_13_Docn_Syntax.html ]
for these ways of defining and reusing pieces of logic and algebra
in your documents. A quick example: a circle
might be described by
Net{radius:Positive Real, center:Point, area:=π*radius^2, ...}.

For a complete listing of pages in this part of my site by topic see
[ home.html ]

The notation used here is a formal language with syntax
and a semantics described using traditional formal logic
[ logic_0_Intro.html ]
plus sets, functions, relations, and other mathematical extensions.