Use 'definition' environment instead of "definition tables"

chapters/annotations.tex

@@ -1890,26 +1890,27 @@ \section{Annotations for Access Control to Protect Intellectual Property}\double
 different encryption formats.
 \end{nonnormative}
 
-Definitions:
-\begin{longtable}[]{|p{2.5cm}|p{12cm}|}
-\hline
-\tablehead{Term} & \tablehead{Description}\\ \hline
-\endhead
-\firstuse{Protection} & Define what parts of a class are visible.\\
-\hline
-\firstuse{Obfuscation} & Changing a Modelica class or generated code so that it is difficult to inspect by a user
-(e.g.\ by automatically renaming variables to non-meaningful names).\\
-\hline
-\firstuse{Encryption} & Encoding of a model or a package in a form so that
-the modeler cannot inspect any content of a class without an appropriate
-key. An encrypted package that has the \lstinline!Protection! annotation is
-read-only; the way to modify it is to generate a new encrypted version.\\
-\hline
-\firstuse{Licensing} & Restrict the use of an encrypted package for particular users for a specified period of time.\\
-\hline
-\end{longtable}
+The following definitions relate to access control.
+
+\begin{definition}[Protection]
+Define what parts of a class are visible.
+\end{definition}
+
+\begin{definition}[Obfuscation]
+Changing a Modelica class or generated code so that it is difficult to inspect by a user (e.g.\ by automatically renaming variables to non-meaningful names).
+\end{definition}
+
+\begin{definition}[Encryption]
+Encoding of a model or a package in a form so that the modeler cannot inspect any content of a class without an appropriate key.  An encrypted package that has the \lstinline!Protection! annotation
+is read-only; the way to modify it is to generate a new encrypted version.
+\end{definition}
+
+\begin{definition}[Licensing]
+Restrict the use of an encrypted package for particular users for a specified period of time.
+\end{definition}
 
 In this section annotations are defined for protection and licensing.  Obfuscation and encryption are not standardized.
+
 Protection and licensing are both defined inside the \lstinline!Protection! annotation:
 \begin{lstlisting}[language=modelica]
 annotation(Protection($\ldots$));

chapters/interface.tex

@@ -16,67 +16,49 @@ \chapter{Interface or Type Relationships}\doublelabel{interface-or-type-relation
 scientists). A short summary of the terms is given in the following
 table. The details are defined in the rest of this chapter.
 
-\begin{longtable}{|p{4cm}|p{8cm}|}
-\hline \endhead
-\tablehead{Term} & \tablehead{Description}\\ \hline
-type or interface
-& The ``essential'' part of the public declaration sections of a class
+\begin{definition}[Type \emph{or} interface]
+The ``essential'' part of the public declaration sections of a class
 that is needed to decide whether \lstinline!A! can be used instead of \lstinline!B!.
 \par
 \begin{nonnormative*}
 E.g.\ a declaration \lstinline!Real x! is part of the type (also called \emph{interface}), but \lstinline!import A! is not.
 \end{nonnormative*}
-\\ \hline
-\begin{tabular}{@{}p{4cm}@{}}
-class type or\\
-inheritance interface
-\end{tabular}
-&
-The ``essential'' part of the public \emph{and protected} declaration
-sections of a class that is needed to decide whether \lstinline!A! can be used
-instead of \lstinline!B!. The class type, also called inheritance interface, is
-needed when inheritance takes place, since then the protected
-declarations have to be taken into account.\\ \hline
-\begin{tabular}{@{}p{4cm}@{}}
-subtype or\\
-compatible interface
-\end{tabular} &
-\lstinline!A! is a subtype of \lstinline!B!, or equivalently, the interface of \lstinline!A! is compatible
-to the interface of \lstinline!B!, if the ``essential'' part of the public
-declaration sections of \lstinline!B! is also available in \lstinline!A!.
+\end{definition}
+
+\begin{definition}[Class type \emph{or} inheritance interface]
+The ``essential'' part of the public \emph{and protected} declaration sections of a class that is needed to decide whether \lstinline!A! can be used instead of \lstinline!B!. The class type, also
+called inheritance interface, is needed when inheritance takes place, since then the protected declarations have to be taken into account.
+\end{definition}
+
+\begin{definition}[Subtype \emph{or} compatible interface]
+\lstinline!A! is a subtype of \lstinline!B!, or equivalently, the interface of \lstinline!A! is compatible to the interface of \lstinline!B!, if the ``essential'' part of the public declaration
+sections of \lstinline!B! is also available in \lstinline!A!.
 \par
 \begin{nonnormative*}
-E.g., if \lstinline!B! has a declaration \lstinline!Real x!, this declaration must also be present in \lstinline!A!.  If \lstinline!A! has a
-declaration \lstinline!Real y!, this declaration must not be present in \lstinline!B!.
+E.g., if \lstinline!B! has a declaration \lstinline!Real x!, this declaration must also be present in \lstinline!A!.  If \lstinline!A! has a declaration \lstinline!Real y!, this declaration must
+not be present in \lstinline!B!.
 \end{nonnormative*}
-\\ \hline
-\begin{tabular}{@{}p{4cm}@{}}
-restricted subtype or plug compatible interface
-\end{tabular} &
-\lstinline!A! is a restricted subtype of \lstinline!B!, or equivalently, the interface of \lstinline!A! is
-plug compatible to the interface of \lstinline!B!, if \lstinline!A! is a subtype of \lstinline!B! and if
-connector components in \lstinline!A! that are not in \lstinline!B!, are default connectable.
+\end{definition}
+
+\begin{definition}[Restricted subtype \emph{or} plug compatible interface]
+\lstinline!A! is a restricted subtype of \lstinline!B!, or equivalently, the interface of \lstinline!A! is plug compatible to the interface of \lstinline!B!, if \lstinline!A! is a subtype of
+\lstinline!B! and if connector components in \lstinline!A! that are not in \lstinline!B!, are default connectable.
 \begin{nonnormative}
 E.g.\ it is not allowed that these connectors have variables with the \lstinline!input! prefix, because then they must be connected.
 \end{nonnormative}
-A model or block \lstinline!A! cannot be used instead of \lstinline!B!, if the particular
-situation does not allow to make a connection to these additional
-connectors. In such a case the stricter \emph{plug compatible} is required
-for a redeclaration.\\ \hline
-\begin{tabular}{@{}p{4cm}@{}}
-function subtype or\\
-function compatible interface
-\end{tabular} &
-\lstinline!A! is a function subtype of \lstinline!B!, or equivalently, the interface of \lstinline!A! is
-function compatible to the interface of \lstinline!B!, if \lstinline!A! is a subtype of \lstinline!B! and if
-the additional arguments of function \lstinline!A! that are not in function \lstinline!B! are
-defined in such a way, that \lstinline!A! can be called at places where \lstinline!B! is called.
+A model or block \lstinline!A! cannot be used instead of \lstinline!B!, if the particular situation does not allow to make a connection to these additional connectors. In such a case the stricter
+\emph{plug compatible} is required for a redeclaration.
+\end{definition}
+
+\begin{definition}[Function subtype \emph{or} function compatible interface]
+\lstinline!A! is a function subtype of \lstinline!B!, or equivalently, the interface of \lstinline!A! is function compatible to the interface of \lstinline!B!, if \lstinline!A! is a subtype of
+\lstinline!B! and if the additional arguments of function \lstinline!A! that are not in function \lstinline!B! are defined in such a way, that \lstinline!A! can be called at places where
+\lstinline!B! is called.
 \par
 \begin{nonnormative*}
 E.g.\ an additional argument must have a default value.
 \end{nonnormative*}
-\\ \hline
-\end{longtable}
+\end{definition}
 
 \section{The Concepts of Type, Interface and Subtype}\doublelabel{the-concepts-of-type-interface-and-subtype}
 

chapters/introduction.tex

@@ -91,31 +91,22 @@ \section{Scope of the Specification}\doublelabel{scope-of-the-specification}
 
 \section{Some Definitions}\doublelabel{some-definitions}
 
-The semantic specification should be read together with the Modelica
-grammar. Non-normative text, i.e., examples and comments, are enclosed
-in {[}\ldots{]} and set in italics. Additional terms are explained
-in the glossary in \autoref{glossary}. Some important terms are:
-\par% The 'tabular' environment doesn't take care of breaking the current line.
-\begin{tabular}{|l|p{10cm}|}
-\hline
-\tablehead{Term} & \tablehead{Definition} \\
-\hline
-Component & An element defined by the production
-\lstinline!component-clause! in the Modelica grammar (basically a
-variable or an instance of a class)\\
-Element & Class definitions, extends-clauses and
-component-clauses declared in a class (basically a class
-reference or a component in a declaration).\\
-Flattening & The translation of a model described in Modelica to the
-corresponding model described as a hybrid DAE, involving expansion of
-inherited base classes, parameterization of base classes, local classes
-and components, and generation of connection equations from
-connect-equations (basically, mapping the hierarchical structure of a
-model into a set of differential, algebraic and discrete equations
-together with the corresponding variable declarations and function
-definitions from the model).\\
-\hline
-\end{tabular}
+The semantic specification should be read together with the Modelica grammar.  Non-normative text, i.e., examples and comments, are enclosed in {[}\ldots{]} and set in italics.  Additional terms
+are explained in the glossary in \autoref{glossary}.  Some important terms are defined below.
+
+\begin{definition}[Component]
+An element defined by the production \lstinline!component-clause! in the Modelica grammar (basically a variable or an instance of a class)
+\end{definition}
+
+\begin{definition}[Element]
+Class definitions, extends-clauses and component-clauses declared in a class (basically a class reference or a component in a declaration).
+\end{definition}
+
+\begin{definition}[Flattening]
+The translation of a model described in Modelica to the corresponding model described as a hybrid DAE, involving expansion of inherited base classes, parameterization of base classes, local classes
+and components, and generation of connection equations from connect-equations (basically, mapping the hierarchical structure of a model into a set of differential, algebraic and discrete equations
+together with the corresponding variable declarations and function definitions from the model).
+\end{definition}
 
 \section{Notation and Grammar}\doublelabel{notation-and-grammar}