-
Notifications
You must be signed in to change notification settings - Fork 1
/
compliance.tex
213 lines (177 loc) · 9.59 KB
/
compliance.tex
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
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
\chapter{\OM Compliance}\label{cha_comp}
Applications that meet the requirements specified in this chapter may label themselves as
\emph{OpenMath compliant}. \OM compliance is defined so as to maximize the potential for
interoperability amongst \OM applications.
\section{Encodings}\label{sec_compl_encoding}
This standard defines two reference encodings for \OM, the binary encoding and \XML
encoding, defined in \ref{cha_enco}.
As a minimum, an \OM compliant application, which accepts or generates \OM objects,
\emph{must} be capable of doing so using the \XML encoding. The ability to use other
encodings is optional.
\subsection{The XML Encoding}\label{sec_compl_xml_encoding}
\subsubsection{Generating Valid XML}\label{sec_compl_xml_encoding_val}
All \OM objects generated by a compliant \OM application must validate against the Relax
NG Schema given in \ref{app_openmath.rng}.
\subsubsection{Decimal versus Hexadecimal Float Representation}\label{sec_compl_xml_encoding_float}
In the \XML encoding, floating-point numbers may be defined using either decimal or
hexadecimal notation. For numerical values, plus the two infinities, the two
representations may be used interchangeably since there is a one-to-one correspondence
between them. The exceptional case is that of \emph{not a number} (NaN) which is defined
in the IEEE standard \cite{ieee754_85} to be any number whose exponent has the maximum
possible value (in this case the exponent is 11 bits so the maximum value is 2047) and
whose mantissa is non-zero. The standard explicitly notes the use of the 52 bits in the
mantissa (and also the sign bit) to store information about how the NaN was generated in a
system-specific way. Thus in some cases the exact representation of the NaN is
significant.
The semantics of the \OM object \lstinline|<OMF dec="NaN"/>| is that it represents
\emph{any} NaN, and a phrasebook may substitute any specific NaN value when processing it.
The semantics of a NaN in hexadecimal notation however, such as
\lstinline|<OMF hex="FFF8000000000001"/>|, is that this is a specific NaN, as distinct from all others.
If a phrasebook author substitutes another value for the NaN or maps all NaNs to a single
object then he or she must recognise that this process is not an identity transformation.
\section{\OM Foreign Objects}\label{sec_compl_omforeign}
An \OM Foreign Object may be attributed with a string indicating the format of its
contents. Although this information is optional, an \OM-compliant application which
generates \OM Foreign Objects should always include it where possible (see the discussion
of MathML conversion below for an example of a situation where it is not always possible).
It is recommended that, where the contents of the Foreign Object are in an \XML dialect,
the namespace \cite{xmlns} of the \XML dialect is used as the value of the encoding. For
example (using the \XML encoding):
\begin{lstlisting}
<OMATTR>
<OMATP>
<OMS cd="annotations1" name="description"/>
<OMFOREIGN encoding="http://www.w3.org/1999/xhtml">
<html xmlns="http://www.w3.org/1999/xhtml">
<head><title>E</title></head>
<body>
<p>
The base of the natural logarithms, approximately 2.71828.
</p>
</body>
</html>
</OMFOREIGN>
</OMATP>
<OMS cd="nums1" name="e"/>
</OMATTR>
\end{lstlisting}
Where the contents of the Foreign Object is a format other than \XML, it is recommended
that its MIME type \cite{rfc2046} is used as the value of the encoding. For example
(again using the \XML encoding):
\begin{lstlisting}
<OMATTR>
<OMATP>
<OMS cd="annotations1" name="description"/>
<OMFOREIGN encoding="text/latex">
\documentclass{article}
\begin{document}
\title{E}
\maketitle
The base of the natural logarithms, approximately 2.71828.
\end{document}
</OMFOREIGN>
</OMATP>
<OMS cd="nums1" name="e"/>
</OMATTR>
\end{lstlisting}
An exception to the above guidelines occurs when a MathML object is converted to \OM.
MathML also has an \lstinline|encoding| attribute which can appear in various places and
whose format is a string. Only two values are predefined, \lstinline|MathML-Content| and
\lstinline|MathML-Presentation|, and these may appear in the resulting \OM object despite
the fact that they are not namespaces as recommended above. For example the following
MathML expression:
\begin{lstlisting}
<semantics xmlns="xmlns="http://www.w3.org/1998/Math/MathML">
<apply>
<sin/>
<ci>x</ci>
</apply>
<annotation encoding="MathML-Presentation">
<math>
<mi>sin</mi><mfenced><mi>x</mi></mfenced>
</math>
</annotation>
</semantics>
\end{lstlisting}
is equivalent to the \OM expression:
\begin{lstlisting}
<OMATTR>
<OMATP>
<OMS cd="altenc" name="MathML_encoding"/>
<OMFOREIGN encoding="MathML-Presentation">
<math xmlns="http://www.w3.org/1998/Math/MathML">
<mi>sin</mi><mfenced><mi>x</mi></mfenced>
</math>
</OMFOREIGN>
</OMATP>
<OMA>
<OMS cd="transc1" name="sin"/>
<OMV name="x"/>
</OMA>
</OMATTR>
\end{lstlisting}
Since in MathML the \lstinline|encoding| attribute is in effect optional (its default
value is the empty string), a convertor program may not in fact be able to provide a value
for the \OM \lstinline|encoding| attribute. This is unfortunate but unavoidable.
\section{Content Dictionaries}\label{sec_compl_cd}
An \OM compliant application \emph{must} be able to support the error Content Dictionary
defined in \ref{errorcd}.
A compliant application must declare the names and version numbers of the Content
Dictionaries that it supports. Equivalently it may declare the Content Dictionary Group
(or groups) and major version number (not revision number), rather than listing individual
Content Dictionaries. Applications that support all Content Dictionaries (e.g. renderers)
should refer to the implicit CD Group \lstinline|all|.
If a compliant application supports a Content Dictionary then it must explicitly declare
any symbols in the Content Dictionaries that are not supported. Phrasebooks are encouraged
to support every symbol in the Content Dictionaries.
Symbols which are not listed as unsupported are \emph{supported} by the application. The
meaning of \emph{supported} will depend on the application domain. For example an \OM
renderer should provide a default display for any \OM object that only references
supported symbols, whereas a Computer Algebra System will be expected to map such an
object to a suitable internal representation, in this system, of this mathematical
object. It is expected that the application's \emph{phrasebooks} for supported Content
Dictionaries will be constructed such that properties of the symbol expressed in the
Content Dictionary are respected as far as possible for the given application
domain. However \OM compliance does \emph{not} imply any guarantee by the \OM Society on
the accuracy of these representations.
Content Dictionaries available from the official \OM repository at www.openmath.org need
only be referenced by name, other Content Dictionaries \emph{should} be referenced using
the \lstinline|CDBase| and the \lstinline|CDName|.
When receiving an \OM symbol, e.g.~$s$, that is not a supported Content Dictionary, a
compliant application will act as if it had received the \OM object
\[\error{unhandled\_symbol,s}\]
where \lstinline|unhandled_symbol| is the symbol from the error Content Dictionary.
Similarly if it receives a symbol, e.g. $s$, from an unsupported Content Dictionary, it
will act as if it had received the \OM object
\[\error{unsupported\_cd,s}\]
Finally if the compliant application receives a symbol from a supported Content Dictionary
but with an unknown name, then this must either be an incorrect object, or possibly the
object has been built using a later version of the Content Dictionary. In either case, the
application will act as if it had received the \OM object
\[\error{unexpected\_symbol,s}\]
\section{Lexical Errors}\label{sec_comp_lex}
The previous section defines the behaviour of a compliant application upon receiving well
formed \OM objects containing unexpected symbols. This standard does not specify any
behaviour for an application upon receiving ill-formed objects.
\section{\OM~1 Objects}\label{sec_compl_om1}
Compliant \OM~2 documents and Content Dictionary files using the reference \XML encodings
must be valid according to the specified schema, and so will use the namespaces
\url{http://www.openmath.org/OpenMath} and \url{http://www.openmath.org/OpenMathCD}
respectively. Similarly CD Group and Signature files will use
\url{http://www.openmath.org/OpenMathCDG} and \url{http://www.openmath.org/OpenMathCDS}.
Applications may also support \OM~1. \XML-encoded \OM~1 documents may be in either the
\url{http://www.openmath.org/OpenMath} namespace or in no-namespace (i.e., do not
have any xmlns declarations). An application may accept either of these forms. Note
however that \OM documents that have a version attribute should validate against the
schema for \OM~2 (or later versions) and so should always use the \OM namespace.
\XML-encoded \OM~1 CD files, CD Group files and CD Signature files must be in
no-namespace. An \OM~2 application may support these files by implicitly converting the
documents to their respective namespace. Apart from this change of namespace (and the
addition of a version attribute on \lstinline|OMOBJ|) the \OM~1 documents should conform
to the schema specified in this standard.
The use of documents in no-namespace should be restricted to reading existing \OM~1 files.
No \OM~2 application should generate documents in this form.
%%% Local Variables:
%%% mode: latex
%%% TeX-master: "omstd20"
%%% End: