File: chapter2-d.html

package info (click to toggle)
w3-recs 20110107-1
links: PTS, VCS
area: non-free
in suites: bullseye, buster, jessie, jessie-kfreebsd, stretch, wheezy
size: 195,972 kB
ctags: 48,964
sloc: xml: 67,284; makefile: 115; perl: 31
file content (1677 lines) | stat: -rw-r--r-- 97,193 bytes
<!DOCTYPE html
  PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
   <head>
      <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
      <title>MathML Fundamentals</title><style type="text/css">

.egmeta {
color:#5555AA;font-style:italic;font-family:serif;font-weight:bold;
}

table.syntax {
font-size: 75%;
background-color: #DDDDDD;
border: thin  solid;
}
table.syntax td {
border: solid thin;
}
table.syntax th {
text-align: left;
}

table.attributes td { padding-left:0.5em; padding-right:0.5em; }
table.attributes td.attname { white-space:nowrap; vertical-align:top;}
table.attributes td.attdesc { background-color:#F0F0FF; padding-left:2em; padding-right:2em}

th.uname {font-size: 50%; text-align:left;}
code           { font-family: monospace; }

div.constraint,
div.issue,
div.note,
div.notice     { margin-left: 2em; }

li p           { margin-top: 0.3em;
                 margin-bottom: 0.3em; }

div.exampleInner pre { margin-left: 1em;
                       margin-top: 0em; margin-bottom: 0em}
div.exampleOuter {border: 4px double gray;
                  margin: 0em; padding: 0em}
div.exampleInner { background-color: #d5dee3;
                   border-top-width: 4px;
                   border-top-style: double;
                   border-top-color: #d3d3d3;
                   border-bottom-width: 4px;
                   border-bottom-style: double;
                   border-bottom-color: #d3d3d3;
                   padding: 4px; margin: 0em }
div.exampleWrapper { margin: 4px }
div.exampleHeader { font-weight: bold;
                    margin: 4px}
a.mainindex {font-weight: bold;}
li.sitem {list-style-type: none;}

  .error { color: red }

  div.mathml-example {border:solid thin black;
              padding: 0.5em;
              margin: 0.5em 0 0.5em 0;
             }
  div.strict-mathml-example {border:solid thin black;
              padding: 0.5em;
              margin: 0.5em 0 0.5em 0;
             }
  div.strict-mathml-example h5 {
  margin-top: -0.3em;
  margin-bottom: -0.5em;}
  var.meta {background-color:green}
  var.transmeta {background-color:red}
  pre.mathml {padding: 0.5em;
              background-color: #FFFFDD;}
  pre.mathml-fragment {padding: 0.5em;
              background-color: #FFFFDD;}
  pre.strict-mathml {padding: 0.5em;
              background-color: #FFFFDD;}
  .minitoc { border-style: solid;
             border-color: #0050B2; 
             border-width: 1px ;
             padding: 0.3em;}
  .attention { border-style: solid; 
               border-width: 1px ; 
               color: #5D0091;
               background: #F9F5DE; 
               border-color: red;
               margin-left: 1em;
               margin-right: 1em;
               margin-top: 0.25em;
               margin-bottom: 0.25em; }

  .attribute-Name { background: #F9F5C0; }
  .method-Name { background: #C0C0F9; }
  .IDL-definition { border-style: solid; 
               border-width: 1px ; 
               color: #001000;
               background: #E0FFE0; 
               border-color: #206020;
               margin-left: 1em;
               margin-right: 1em;
               margin-top: 0.25em;
               margin-bottom: 0.25em; }
  .baseline {vertical-align: baseline}

  #eqnoc1 {width: 10%}
  #eqnoc2 {width: 80%; text-align: center; }
  #eqnoc3 {width: 10%; text-align: right; }

div.div1 {margin-bottom: 1em;}
          
.h3style {
  text-align: left;
  font-family: sans-serif;
  font-weight: normal;
  color: #0050B2; 
  font-size: 125%;
}

  h4 { text-align: left;
       font-family: sans-serif;
       font-weight: normal;
       color: #0050B2; }
  h5 { text-align: left;
       font-family: sans-serif;
       font-weight: bold;
       color: #0050B2; } 

  th {background:  #E0FFE0;}

  p, blockquote, h4 { font-family: sans-serif; }
  dt, dd, dl, ul, li { font-family: sans-serif; }
  pre, code { font-family: monospace }

  a.termref {
  text-decoration: none;
  color: black;
  }

sub.diff-link {background-color: black; color: white; font-family:
sans-serif; font-weight: bold;}

.diff-add  { background-color: #FFFF99}
.diff-del  { background-color: #FF9999; text-decoration: line-through }
.diff-chg  { background-color: #99FF99 }
.diff-off  {  }


.mathml-render {
font-family: serif;
font-size: 130%;
border: solid 4px green;
padding-left: 1em;
padding-right: 1em;
}
</style><link rel="stylesheet" type="text/css" href="../../../StyleSheets/TR/W3C-REC.css">
   </head>
   <body>
      
      <h1><a name="fund" id="fund"></a>2 MathML Fundamentals
      </h1>
      <!-- TOP NAVIGATION BAR -->
      <div class="minitoc">
         
         Overview: <a href="Overview-d.html">Mathematical Markup Language (MathML) Version 3.0</a><br>
         Previous: 1 <a href="chapter1-d.html">Introduction</a><br>
         Next: 3 <a href="chapter3-d.html">Presentation Markup</a><br><br>2 <a href="chapter2-d.html">MathML Fundamentals</a><br>&nbsp;&nbsp;&nbsp;&nbsp;2.1 <a href="chapter2-d.html#fund.syntax">MathML Syntax and Grammar</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.1.1 <a href="chapter2-d.html#fund.xmlgeneral">General Considerations</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.1.2 <a href="chapter2-d.html#interf.namespace">MathML and Namespaces</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.1.3 <a href="chapter2-d.html#fund.xmlsyntax">Children versus Arguments</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.1.4 <a href="chapter2-d.html#fund.renderingmodel">MathML and Rendering</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.1.5 <a href="chapter2-d.html#fund.attval">MathML Attribute Values</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.1.5.1 <a href="chapter2-d.html#id.2.1.5.1">Syntax notation used in the MathML specification</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.1.5.2 <a href="chapter2-d.html#fund.units">Length Valued Attributes</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.1.5.3 <a href="chapter2-d.html#fund.color">Color Valued Attributes</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.1.5.4 <a href="chapter2-d.html#fund.defaults">Default values of attributes</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.1.6 <a href="chapter2-d.html#fund.globatt">Attributes Shared by all MathML Elements</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.1.7 <a href="chapter2-d.html#fund.collapse">Collapsing Whitespace in Input</a><br>&nbsp;&nbsp;&nbsp;&nbsp;2.2 <a href="chapter2-d.html#interf.toplevel">The Top-Level 
            <code>math</code> Element</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.2.1 <a href="chapter2-d.html#interf.toplevel.atts">Attributes</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.2.2 <a href="chapter2-d.html#id.2.2.2">Deprecated Attributes</a><br>&nbsp;&nbsp;&nbsp;&nbsp;2.3 <a href="chapter2-d.html#interf.genproc">Conformance</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.3.1 <a href="chapter2-d.html#fund.mathmlconf">MathML Conformance</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.3.1.1 <a href="chapter2-d.html#interf.testsuite">MathML Test Suite and Validator</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.3.1.2 <a href="chapter2-d.html#interf.deprec">Deprecated MathML 1.x and MathML 2.x Features</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.3.1.3 <a href="chapter2-d.html#interf.extension">MathML 
            Extension Mechanisms and Conformance</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.3.2 <a href="chapter2-d.html#interf.error">Handling of Errors</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.3.3 <a href="chapter2-d.html#interf.unspecified">Attributes for unspecified data</a><br></div>
      <div class="div1">
         <div class="div2">
            
            <h2><a name="fund.syntax" id="fund.syntax"></a>2.1 MathML Syntax and Grammar
            </h2>
            <div class="div3">
               
               <h3><a name="fund.xmlgeneral" id="fund.xmlgeneral"></a>2.1.1 General Considerations
               </h3>
               <p>MathML is an application of <a href="appendixg-d.html#XML">[XML]</a>, 
                  Extensible Markup Language, and as such it is governed by the rules of
                  XML syntax. XML syntax is a notation for rooted labeled planar trees.
                  Planarity means that the children of a node may be viewed as given a
                  natural order and MathML depends on this order.
                  
               </p>
               <p>The basic ‘syntax’ of MathML is thus defined by XML.
                  Upon this, we layer a ‘grammar’, being the rules for allowed elements,
                  the order in which they can appear,
                  and how they may be contained within each other,
                  as well as additional syntactic rules for the values of attributes.
                  These rules are defined by this specification,
                  and formalized by a RelaxNG schema  <a href="appendixg-d.html#RELAX-NG">[RELAX-NG]</a>.
                  The RelaxNG Schema is normative, but a DTD (Document Type Definition)
                  and an XML Schema <a href="appendixh-d.html#XMLSchemas">[XMLSchemas]</a> are provided
                  for continuity (they were normative for MathML2).
                  See <a href="appendixa-d.html">Appendix&nbsp;A Parsing MathML</a>.
                  
               </p>
               <p>As an XML vocabulary, MathML's character set must consist of legal characters 
                  as specified by Unicode <a href="appendixg-d.html#Unicode">[Unicode]</a>.
                  The use of Unicode characters for mathematics is 
                  discussed in <a href="chapter7-d.html">Chapter&nbsp;7 Characters, Entities and Fonts</a>.
               </p>
               <p>The following sections discuss the general aspects
                  of the MathML grammar as well as describe the syntaxes used
                  for attribute values.
                  
               </p>
            </div>
            <div class="div3">
               
               <h3><a name="interf.namespace" id="interf.namespace"></a>2.1.2 MathML and Namespaces
               </h3>
               <p>An XML namespace <a href="appendixg-d.html#Namespaces">[Namespaces]</a> is a collection of names identified by a URI.
                  The URI for the MathML namespace is:
               </p><pre>
http://www.w3.org/1998/Math/MathML
</pre><p>To declare a namespace, one uses an <code>xmlns</code>
                  attribute, or an attribute with an <code>xmlns</code> prefix.
                  When the <code>xmlns</code> attribute is used alone, it sets 
                  the default namespace for the element on which it
                  appears, and for any child elements.  For example:
               </p><pre>
&lt;math xmlns="http://www.w3.org/1998/Math/MathML"&gt;
&lt;mrow&gt;...&lt;/mrow&gt;
&lt;/math&gt;
</pre><p>When the <code>xmlns</code> attribute is used as a
                  prefix, it declares a prefix which can then be used to explicitly associate other elements
                  and attributes with a particular namespace.
                  When embedding MathML within XHTML, one might use:
                  
               </p><pre>
&lt;body xmlns:m="http://www.w3.org/1998/Math/MathML"&gt;
...
&lt;m:math&gt;&lt;m:mrow&gt;...&lt;/m:mrow&gt;&lt;/m:math&gt;
...
&lt;/body&gt;
</pre></div>
            <div class="div3">
               
               <h3><a name="fund.xmlsyntax" id="fund.xmlsyntax"></a>2.1.3 Children versus Arguments
               </h3>
               <p>Most MathML elements act as ‘containers’; such an element's 
                  children are not distinguished from each other except as individual members of the 
                  list of children.  Commonly there is no limit imposed on the number of children
                  an element may have.  This is the case for most presentation
                  elements and some content elements such as <code>set</code>. 
                  But many
                  MathML elements require a specific number of children, or
                  attach a particular meaning to children in certain positions.
                  Such elements are best considered to represent constructors of mathematical
                  objects, and hence thought of as functions of their children.  Therefore
                  children of such a MathML element 
                  will often be referred to as its <em>arguments</em> instead of merely as children.
                  Examples of this can be found, say, in <a href="chapter3-d.html#presm.reqarg">Section&nbsp;3.1.3 Required Arguments</a>.
                  
               </p>
               <p>There are presentation elements that conceptually accept only
                  a single argument, but which for convenience have been written to accept any number of children;
                  then we infer an <code>mrow</code> containing those children which acts as
                  the argument to the element in question; see <a href="chapter3-d.html#presm.inferredmrow">Section&nbsp;3.1.3.1 Inferred <code>&lt;mrow&gt;</code>s</a>.
                  
               </p>
               <p>In the detailed discussions of element syntax given with each
                  element throughout the MathML specification, the correspondence
                  of children with arguments, the number of arguments required and
                  their order, as well as other constraints on the content, are specified.
                  This information is also tabulated
                  for the presentation elements in <a href="chapter3-d.html#presm.reqarg">Section&nbsp;3.1.3 Required Arguments</a>.
               </p>
            </div>
            <div class="div3">
               
               <h3><a name="fund.renderingmodel" id="fund.renderingmodel"></a>2.1.4 MathML and Rendering
               </h3>
               <p>MathML presentation elements only recommend (i.e., do not require)
                  specific ways of rendering; this is in order to allow for medium-dependent
                  rendering and for individual preferences of style.
               </p>
               <p>Nevertheless, some parts of this specification describe these
                  recommended visual rendering rules in detail; in those
                  descriptions it is often assumed that the model of rendering
                  used supports the concepts of a well-defined 'current rendering
                  environment' which, in particular, specifies a 'current font',
                  a 'current display' (for pixel size) and a 'current baseline'.
                  The 'current font' provides certain metric properties and an
                  encoding of glyphs.
               </p>
            </div>
            <div class="div3">
               
               <h3><a name="fund.attval" id="fund.attval"></a>2.1.5 MathML Attribute Values
               </h3>
               <p>MathML elements take attributes with values that further specialize
                  the meaning or effect of the element. Attribute names are shown in a
                  <code>monospaced</code> font throughout this document. The meanings of attributes and their
                  allowed values are described within the specification of each element. 
                  The syntax notation explained in this section is used in specifying allowed values.
                  
               </p>
               <p>Except when explicitly forbidden by the specification for an attribute,
                  MathML attribute values may contain any legal characters specified by
                  the XML recommendation. See <a href="chapter7-d.html">Chapter&nbsp;7 Characters, Entities and Fonts</a> for further
                  clarification.
                  
               </p>
               <div class="div4">
                  
                  <h4><a name="id.2.1.5.1" id="id.2.1.5.1"></a>2.1.5.1 Syntax notation used in the MathML specification
                  </h4>
                  <p>To  describe  the  MathML-specific  syntax  of 
                     attribute values, the  following conventions and notations are
                     used for most attributes in the present document.  
                     We use below the notation
                     beginning with U+ that is recommended by Unicode
                     for referring to Unicode characters [see <a href="appendixg-d.html#Unicode">[Unicode]</a>, page
                     xxviii].
                     
                  </p>
                  <table border="1" id="fund.table-attval">
                     <thead>
                        <tr>
                           <th>Notation</th>
                           <th>What it matches</th>
                        </tr>
                     </thead>
                     <tbody>
                        <tr>
                           <td id="type.digit"><em>decimal-digit</em></td>
                           <td>a decimal digit from the range U+0030 to U+0039</td>
                        </tr>
                        <tr>
                           <td id="type.hexdigit"><em>hexadecimal-digit</em></td>
                           <td>a hexadecimal (base 16) digit from the ranges U+0030 to U+0039, U+0041 to 
                              U+0046 and  U+0061 to U+0066
                           </td>
                        </tr>
                        <tr>
                           <td id="type.unsigned-integer"><em>unsigned-integer</em></td>
                           <td>a string of <a href="chapter2-d.html#type.digit"><em>decimal-digit</em></a>s,
                              representing a non-negative integer
                           </td>
                        </tr>
                        <tr>
                           <td id="type.positive-integer"><em>positive-integer</em></td>
                           <td>a string of <a href="chapter2-d.html#type.digit"><em>decimal-digit</em></a>s,
                              but not consisting solely of "0"s (U+0030), representing a positive integer
                           </td>
                        </tr>
                        <tr>
                           <td id="type.integer"><em>integer</em></td>
                           <td>an optional "-"  (U+002D), followed by a string of 
                              <a href="chapter2-d.html#type.digit"><em>decimal digit</em></a>s,
                              and representing an integer
                              
                           </td>
                        </tr>
                        <tr>
                           <td id="type.unsigned-number"><em>unsigned-number</em></td>
                           <td>
                              a string of <a href="chapter2-d.html#type.digit"><em>decimal digit</em></a>s 
                              with up to one decimal point (U+002E), 
                              representing a non-negative terminating decimal number 
                              (a type of rational number)
                           </td>
                        </tr>
                        <tr>
                           <td id="type.number"><em>number</em></td>
                           <td>
                              an optional prefix of "-" (U+002D), followed by an unsigned number,  
                              representing a terminating decimal number (a type of rational number)
                           </td>
                        </tr>
                        <tr>
                           <td id="type.character"><em>character</em></td>
                           <td>a single non-whitespace character</td>
                        </tr>
                        <tr>
                           <td id="type.string"><em>string</em></td>
                           <td>an arbitrary, nonempty and finite, string of <em>character</em>s
                           </td>
                        </tr>
                        <tr>
                           <td><em>length</em></td>
                           <td>a length, as explained below, <a href="chapter2-d.html#fund.units">Section&nbsp;2.1.5.2 Length Valued Attributes</a></td>
                        </tr>
                        <tr>
                           <td><em>unit</em></td>
                           <td>a unit, typically used as part of a length, as explained below, <a href="chapter2-d.html#fund.units">Section&nbsp;2.1.5.2 Length Valued Attributes</a></td>
                        </tr>
                        <tr>
                           <td><em>namedlength</em></td>
                           <td>a named length, as explained below, <a href="chapter2-d.html#fund.units">Section&nbsp;2.1.5.2 Length Valued Attributes</a></td>
                        </tr>
                        <tr>
                           <td><em>color</em></td>
                           <td>a color, as explained below, <a href="chapter2-d.html#fund.color">Section&nbsp;2.1.5.3 Color Valued Attributes</a></td>
                        </tr>
                        <tr>
                           <td id="type.id"><em>id</em></td>
                           <td>an identifier, unique within the document;
                              must satisfy the NAME syntax of the XML recommendation <a href="appendixg-d.html#XML">[XML]</a></td>
                        </tr>
                        <tr>
                           <td id="type.idref"><em>idref</em></td>
                           <td>an identifier referring to another element within the document;
                              must satisfy the NAME syntax of the XML recommendation <a href="appendixg-d.html#XML">[XML]</a></td>
                        </tr>
                        <tr>
                           <td id="type.uri"><em>URI</em></td>
                           <td>a Uniform Resource Identifier <a href="appendixg-d.html#RFC3986">[RFC3986]</a>. Note that the attribute value
                              is typed in the schema as anyURI which allows any sequence of XML characters. 
                              Systems needing to use this string as a URI must encode the bytes of the UTF-8 encoding of any characters not allowed in URI
                              using %HH encoding where HH are the byte value in hexadecimal.
                              This ensures that such an attribute value may be interpreted as an IRI,
                              or more generally a LEIRI, see  <a href="appendixg-d.html#IRI">[IRI]</a>.
                           </td>
                        </tr>
                        <tr>
                           <td><em>italicized word</em></td>
                           <td>values as explained in the text for each attribute; see <a href="chapter2-d.html#fund.defaults">Section&nbsp;2.1.5.4 Default values of attributes</a></td>
                        </tr>
                        <tr>
                           <td>"literal"</td>
                           <td>quoted symbol, literally present in the attribute value (e.g. "+" or '+')</td>
                        </tr>
                     </tbody>
                  </table>
                  <p>The ‘types’ described above, except for <em>string</em>,
                     may be combined into composite patterns using the following operators. The whole
                     attribute value must be delimited by single (') or double (") quotation marks in the marked up 
                     document.  Note that double quotation marks are often used in this specification to mark up 
                     literal expressions; an example is the "-" in line 5 of the table above.
                     
                  </p>
                  <p>
                     In the table
                     below a form <em>f</em> means an instance of a type described in the table above.
                     The combining operators are shown in order of precedence from highest 
                     to lowest:
                  </p>
                  <table id="fund.table.notn" border="1">
                     <thead>
                        <tr>
                           <th>Notation</th>
                           <th>What it matches</th>
                        </tr>
                     </thead>
                     <tbody>
                        <tr>
                           <td>( <em>f</em> )
                           </td>
                           <td>same as <em>f</em></td>
                        </tr>
                        <tr>
                           <td><em>f</em><code>?</code></td>
                           <td>an optional instance of <em>f</em></td>
                        </tr>
                        <tr>
                           <td><em>f</em> <code>*</code></td>
                           <td>zero or more instances of <em>f</em>, with 
                              separating whitespace characters
                           </td>
                        </tr>
                        <tr>
                           <td><em>f</em> +
                           </td>
                           <td>one or more instances of <em>f</em>, with 
                              separating whitespace characters
                           </td>
                        </tr>
                        <tr>
                           <td><em>f<sub>1</sub> f<sub>2</sub> ... f<sub>n</sub></em></td>
                           <td>one instance of each form <em>f<sub>i</sub></em>, in sequence, 
                              with no separating whitespace
                           </td>
                        </tr>
                        <tr>
                           <td><em>f<sub>1</sub>, f<sub>2</sub>, ..., f<sub>n</sub></em></td>
                           <td>one instance of each form <em>f<sub>i</sub></em>, in sequence, with 
                              separating whitespace characters (but no commas)
                           </td>
                        </tr>
                        <tr>
                           <td><em>f<sub>1</sub></em> | <em>f<sub>2</sub></em> | ... | <em>f<sub>n</sub></em></td>
                           <td>any one of the specified forms <em>f<sub>i</sub></em></td>
                        </tr>
                     </tbody>
                  </table>
                  <p>The notation we have chosen here is in the style of the syntactical notation of the RelaxNG
                     used for MathML's basic schema, <a href="appendixa-d.html">Appendix&nbsp;A Parsing MathML</a>.
                     
                  </p>
                  <p>Since some applications are inconsistent about normalization
                     of whitespace, for maximum interoperability it is advisable to use only
                     a single whitespace character for separating parts of a value.
                     Moreover, leading and trailing whitespace in attribute values should be avoided.
                  </p>
                  <p>For most numerical attributes, only those in a subset of the
                     expressible values are sensible; values outside this subset are not
                     errors, unless otherwise specified, but rather are rounded up or down
                     (at the discretion of the renderer) to the closest value within the
                     allowed subset.  The set of allowed values may depend on the renderer,
                     and is not specified by MathML.
                  </p>
                  <p>If a numerical value within an attribute value syntax description
                     is declared to allow a minus sign ('-'), e.g., <code>number</code> or
                     <code>integer</code>, it is not a syntax error when one is provided in
                     cases where a negative value is not sensible. Instead, the value
                     should be handled by the processing application as described in the
                     preceding paragraph.  An explicit plus sign ('+') is not allowed as
                     part of a numerical value except when it is specifically listed in the
                     syntax (as a quoted '+' or "+"), and its presence can change the
                     meaning of the attribute value (as documented with each attribute
                     which permits it).
                  </p>
               </div>
               <div class="div4">
                  
                  <h4><a name="fund.units" id="fund.units"></a>2.1.5.2 Length Valued Attributes
                  </h4>
                  <p>Most presentation elements have attributes that accept values
                     representing lengths to be used for size, spacing or similar properties.
                     The syntax of a length is specified as
                  </p>
                  <table border="1" id="type.length">
                     <thead>
                        <tr>
                           <th>Type</th>
                           <th>Syntax</th>
                        </tr>
                     </thead>
                     <tbody>
                        <tr>
                           <td><em>length</em></td>
                           <td>
                              <a href="chapter2-d.html#type.number"><em>number</em></a>
                              | <a href="chapter2-d.html#type.number"><em>number</em></a>
                              <a href="chapter2-d.html#type.unit"><em>unit</em></a>
                              | <a href="chapter2-d.html#type.namedspace"><em>namedspace</em></a>
                              
                           </td>
                        </tr>
                     </tbody>
                  </table>
                  <p>There should be no space between the number and the unit of a length.</p>
                  <p>The possible <em>unit</em>s and <em>namedspace</em>s, along with their interpretations, are
                     shown below. Note that although the units and their meanings are taken from
                     CSS, the syntax of lengths is not identical. A few MathML elements
                     have length attributes that accept additional keywords; these are termed pseudo-units 
                     and specified
                     in the description of those particular elements; see, for instance, <a href="chapter3-d.html#presm.mpadded">Section&nbsp;3.3.6 Adjust Space Around Content
                        <code>&lt;mpadded&gt;</code></a>.
                  </p>
                  <p>
                     A trailing "%" represents a percent of the default value.
                     The default value, or how it is obtained,
                     is listed in the table of attributes for each element.
                     (See also <a href="chapter2-d.html#fund.defaults">Section&nbsp;2.1.5.4 Default values of attributes</a>.)
                     A number without a unit is intepreted as a multiple of the default value.
                     This form is primarily for backward compatibility and should be avoided,
                     prefering explicit units for clarity.
                     
                  </p>
                  <p>In some cases, the range of acceptable values for a particular attribute may be restricted;
                     implementations are free to round up or down to the closest allowable value.
                  </p>
                  <p id="type.unit">The possible <em>unit</em>s in MathML are:
                  </p>
                  <table border="1">
                     <thead>
                        <tr>
                           <th>Unit</th>
                           <th>Description</th>
                        </tr>
                     </thead>
                     <tbody>
                        <tr>
                           <td><code>em</code></td>
                           <td>an em (font-relative unit traditionally used for horizontal lengths)</td>
                        </tr>
                        <tr>
                           <td><code>ex</code></td>
                           <td>an ex (font-relative unit traditionally used for vertical lengths)</td>
                        </tr>
                        <tr>
                           <td><code>px</code></td>
                           <td>pixels, or size of a  pixel in the current display</td>
                        </tr>
                        <tr>
                           <td><code>in</code></td>
                           <td>inches (1 inch = 2.54 centimeters)</td>
                        </tr>
                        <tr>
                           <td><code>cm</code></td>
                           <td>centimeters</td>
                        </tr>
                        <tr>
                           <td><code>mm</code></td>
                           <td>millimeters</td>
                        </tr>
                        <tr>
                           <td><code>pt</code></td>
                           <td>points (1 point = 1/72 inch)</td>
                        </tr>
                        <tr>
                           <td><code>pc</code></td>
                           <td>picas (1 pica = 12 points)</td>
                        </tr>
                        <tr>
                           <td><code>%</code></td>
                           <td>percentage of the default value</td>
                        </tr>
                     </tbody>
                  </table>
                  <p>Some additional aspects of units are discussed further 
                     below, in <a href="chapter2-d.html#units.addl.notes">Section&nbsp;2.1.5.2.1 Additional notes about units</a>.
                  </p>
                  <p id="type.namedspace">The following constants, <em>namedspace</em>s,
                     may also be used where a length is needed; they are typically used for
                     spacing or padding between tokens.
                     
                     Recommended default values for these constants are shown;
                     the actual spacing used is implementation specific.
                     
                  </p>
                  <table border="1">
                     <thead>
                        <tr>
                           <th><em>namedspace</em></th>
                           <th>Recommended default</th>
                        </tr>
                     </thead>
                     <tbody>
                        <tr>
                           <td><code>veryverythinmathspace</code></td>
                           <td>1/18<code>em</code></td>
                        </tr>
                        <tr>
                           <td><code>verythinmathspace</code></td>
                           <td>2/18<code>em</code></td>
                        </tr>
                        <tr>
                           <td><code>thinmathspace</code></td>
                           <td>3/18<code>em</code></td>
                        </tr>
                        <tr>
                           <td><code>mediummathspace</code></td>
                           <td>4/18<code>em</code></td>
                        </tr>
                        <tr>
                           <td><code>thickmathspace</code></td>
                           <td>5/18<code>em</code></td>
                        </tr>
                        <tr>
                           <td><code>verythickmathspace</code></td>
                           <td>6/18<code>em</code></td>
                        </tr>
                        <tr>
                           <td><code>veryverythickmathspace</code></td>
                           <td>7/18<code>em</code></td>
                        </tr>
                        <tr>
                           <td><code>negativeveryverythinmathspace</code></td>
                           <td>-1/18<code>em</code></td>
                        </tr>
                        <tr>
                           <td><code>negativeverythinmathspace</code></td>
                           <td>-2/18<code>em</code></td>
                        </tr>
                        <tr>
                           <td><code>negativethinmathspace</code></td>
                           <td>-3/18<code>em</code></td>
                        </tr>
                        <tr>
                           <td><code>negativemediummathspace</code></td>
                           <td>-4/18<code>em</code></td>
                        </tr>
                        <tr>
                           <td><code>negativethickmathspace</code></td>
                           <td>-5/18<code>em</code></td>
                        </tr>
                        <tr>
                           <td><code>negativeverythickmathspace</code></td>
                           <td>-6/18<code>em</code></td>
                        </tr>
                        <tr>
                           <td><code>negativeveryverythickmathspace</code></td>
                           <td>-7/18<code>em</code></td>
                        </tr>
                     </tbody>
                  </table>
                  <div class="div5">
                     
                     <h5><a name="units.addl.notes" id="units.addl.notes"></a>2.1.5.2.1 Additional notes about units
                     </h5>
                     <p>Lengths are only used in MathML for presentation, and presentation
                        will ultimately involve rendering in or on some medium. For visual media,
                        the display context is assumed to have certain properties available to
                        the rendering agent. A <code>px</code> corresponds to a pixel on the display, to
                        the extent that is meaningful. The resolution of the display device
                        will affect the correspondence of pixels to the units
                        <code>in</code>, <code>cm</code>, <code>mm</code>, <code>pt</code> and <code>pc</code>.
                        
                     </p>
                     <p>Moreover, the display context will also provide a default for the font size;
                        the parameters of this font determine the initial values used to interpret
                        the units <code>em</code> and <code>ex</code>, and thus indirectly the sizes
                        of namedspaces. Since these units track the display context, and in particular,
                        the user's preferences for display, the relative units <code>em</code> and <code>ex</code>
                        are generally to be preferred over absolute units such as <code>px</code> or <code>cm</code>.
                        
                     </p>
                     <p>Two additional aspects of relative units must be clarified, however.
                        First, some elements such as <a href="chapter3-d.html#presm.scrlim">Section&nbsp;3.4 Script and Limit Schemata</a> or <code>mfrac</code>,
                        implicitly switch to smaller font sizes for some of their arguments.
                        Similarly, <code>mstyle</code> can be used to explicitly change
                        the current font size. In such cases, the effective values of
                        an <code>em</code> or <code>ex</code> inside those contexts will be
                        different than outside. The second point is that the effective value
                        of an <code>em</code> or <code>ex</code> used for an attribute value
                        can be affected by changes to the current font size.
                        Thus, attributes that affect the current font size,
                        such as <code>mathsize</code>
                        and <code>scriptlevel</code>, must be processed before
                        evaluating other length valued attributes.
                        
                        
                     </p>
                     <p>If, and how, lengths might affect non-visual media is implementation specific.</p>
                  </div>
               </div>
               <div class="div4">
                  
                  <h4><a name="fund.color" id="fund.color"></a>2.1.5.3 Color Valued Attributes
                  </h4>
                  <p>The color, or background color, of presentation elements
                     may be specified as a <em>color</em> using the following syntax:
                  </p>
                  <table border="1" id="type.color">
                     <thead>
                        <tr>
                           <th>Type</th>
                           <th>Syntax</th>
                        </tr>
                     </thead>
                     <tbody>
                        <tr>
                           <td><em>color</em></td>
                           <td>
                              #<a href="chapter2-d.html#type.hexdigit"><em>R</em></a><a href="chapter2-d.html#type.hexdigit"><em>G</em></a><a href="chapter2-d.html#type.hexdigit"><em>B</em></a>
                              | #<a href="chapter2-d.html#type.hexdigit"><em>R</em></a><a href="chapter2-d.html#type.hexdigit"><em>R</em></a><a href="chapter2-d.html#type.hexdigit"><em>G</em></a><a href="chapter2-d.html#type.hexdigit"><em>G</em></a><a href="chapter2-d.html#type.hexdigit"><em>B</em></a><a href="chapter2-d.html#type.hexdigit"><em>B</em></a>
                              | <a href="chapter2-d.html#type.html-color"><em>html-color-name</em></a>
                              
                           </td>
                        </tr>
                     </tbody>
                  </table>
                  <p>A color is specified either by "#" followed
                     by hexadecimal values for the red, green, and blue components,
                     with no intervening whitespace, or by an <em>html-color-name</em>.
                     The color components can be either 1-digit or 2-digit, but
                     must all have the same number of digits; the component
                     ranges from 0 (component not present) to <code>FF</code> (component fully present).
                     Note that, for example, by the digit-doubling rule specified under Colors in 
                     <a href="appendixh-d.html#CSS21">[CSS21]</a>
                     <code>#123</code> is a short form for <code>#112233</code>.
                     
                  </p>
                  <p id="type.html-color">Color values can also be specified as an <em>html-color-name</em>,
                     one of the color-name keywords defined in <a href="appendixg-d.html#HTML4">[HTML4]</a>
                     ("aqua",
                     "black",
                     "blue",
                     "fuchsia",
                     "gray",
                     "green",
                     "lime",
                     "maroon",
                     "navy",
                     "olive",
                     "purple",
                     "red",
                     "silver",
                     "teal",
                     "white", and
                     "yellow").
                     Note that the color name keywords are not case-sensitive, unlike most 
                     keywords in MathML attribute values, for compatibility with CSS and HTML.
                  </p>
                  <p>When a <em>color</em> is applied to an element,
                     it is the color in which the content of tokens is rendered.
                     Additionally, when inherited from a surrounding element or from the environment in which the complete MathML expression is
                     embedded, it controls the color of
                     all other drawing due to MathML elements, including the lines
                     or radical signs that can be drawn in rendering <code>mfrac</code>, <code>mtable</code>, or
                     <code>msqrt</code>.
                  </p>
                  <p>When used to specify a background color, the keyword "transparent"
                     is also allowed.
                     The recommended MathML visual rendering rules do not define the
                     precise extent of the region whose background is affected by using the
                     <code>background</code> attribute on an element,
                     except that, when the element's content does not have
                     negative dimensions and its drawing region is not overlapped by other
                     drawing due to surrounding negative spacing, this region should lie
                     behind all the drawing done to render the content of the
                     element, but should not lie behind any of the
                     drawing done to render surrounding expressions. The effect of overlap
                     of drawing regions caused by negative spacing on the extent of the
                     region affected by the <code>background</code> attribute is not
                     defined by these rules.
                  </p>
               </div>
               <div class="div4">
                  
                  <h4><a name="fund.defaults" id="fund.defaults"></a>2.1.5.4 Default values of attributes
                  </h4>
                  <p>Default values for MathML attributes are, in general, given along with the
                     detailed descriptions of specific elements in the text.  Default values
                     shown in plain text in the tables of attributes for an element are literal,
                     but when italicized are descriptions of how default values can be computed.
                  </p>
                  <p>Default values described as <em>inherited</em> are taken from the
                     rendering environment, as described in <a href="chapter3-d.html#presm.mstyle">Section&nbsp;3.3.4 Style Change <code>&lt;mstyle&gt;</code></a>,
                     or in some cases (which are described individually) taken from the values of other
                     attributes of surrounding elements, or from certain parts of those
                     values. The value used will always be one which could have been specified
                     explicitly, had it been known; it will never depend on the content or
                     attributes of the same element, only on its environment. (What it means
                     when used may, however, depend on those attributes or the content.)
                  </p>
                  <p>Default values described as <em>automatic</em> should be computed by
                     a MathML renderer in a way which will produce a high-quality rendering; how
                     to do this is not usually specified by the MathML specification. The value
                     computed will always be one which could have been specified explicitly, had
                     it been known, but it will usually depend on the element content and
                     possibly on the context in which the element is rendered.
                  </p>
                  <p>Other italicized descriptions of default values which appear in the
                     tables of attributes are explained individually for each attribute.
                  </p>
                  <p>The single or double quotes which are required around attribute values
                     in an XML start tag are not shown in the tables of attribute value syntax
                     for each element, but are around attribute values in examples in the
                     text, so that the pieces of code shown are correct.
                  </p>
                  <p>Note that, in general, there is no mechanism in MathML to simulate the 
                     effect of not specifying attributes which are <em>inherited</em> or
                     <em>automatic</em>.  Giving the words "inherited" or
                     "automatic" explicitly will not work, and is not generally
                     allowed.  Furthermore, the <code>mstyle</code> element (<a href="chapter3-d.html#presm.mstyle">Section&nbsp;3.3.4 Style Change <code>&lt;mstyle&gt;</code></a>)
                     can even be used to change the default values of presentation attributes 
                     for its children.
                  </p>
                  <p>Note also that these defaults describe the
                     behavior of MathML applications when an attribute is not supplied;
                     they do not indicate a value that will be filled in by an XML parser,
                     as is sometimes mandated by DTD-based specifications.
                  </p>
               </div>
            </div>
            <div class="div3">
               
               <h3><a name="fund.globatt" id="fund.globatt"></a>2.1.6 Attributes Shared by all MathML Elements
               </h3>
               <p>In addition to the attributes described specifically for each element,
                  the attributes in the following table are allowed on every MathML element.
                  Also allowed are attributes from the xml namespace, such as <code>xml:lang</code>,
                  and attributes from namespaces other than MathML,
                  which are ignored by default.
               </p>
               <table border="1" class="attributes">
                  <thead>
                     <tr>
                        <th>Name</th>
                        <th>values</th>
                        <th>default</th>
                     </tr>
                  </thead>
                  <tbody>
                     <tr>
                        <td rowspan="2" class="attname">id</td>
                        <td><a href="chapter2-d.html#type.id"><em>id</em></a></td>
                        <td><em>none</em></td>
                     </tr>
                     <tr>
                        <td colspan="2" class="attdesc">
                           Establishes a unique identifier associated with the element
                           to support linking, cross-references and parallel markup.
                           See <code>xref</code> and <a href="chapter5-d.html#mixing.parallel">Section&nbsp;5.4 Parallel Markup</a>.
                           
                        </td>
                     </tr>
                     <tr>
                        <td rowspan="2" class="attname">xref</td>
                        <td><a href="chapter2-d.html#type.idref"><em>idref</em></a></td>
                        <td><em>none</em></td>
                     </tr>
                     <tr>
                        <td colspan="2" class="attdesc">
                           References another element within the document.
                           See <code>id</code> and <a href="chapter5-d.html#mixing.parallel">Section&nbsp;5.4 Parallel Markup</a>.
                           
                        </td>
                     </tr>
                     <tr>
                        <td rowspan="2" class="attname">class</td>
                        <td><a href="chapter2-d.html#type.string"><em>string</em></a></td>
                        <td><em>none</em></td>
                     </tr>
                     <tr>
                        <td colspan="2" class="attdesc">
                           Associates the element with a set of style classes for use with
                           <a href="appendixh-d.html#XSLT">[XSLT]</a> and <a href="appendixh-d.html#CSS21">[CSS21]</a>.
                           Typically this would be a space separated sequence of words,
                           but this is not specified by MathML.
                           See <a href="chapter6-d.html#world-int-style">Section&nbsp;6.5 Using CSS with MathML</a> for discussion of the interaction of MathML and CSS.
                           
                        </td>
                     </tr>
                     <tr>
                        <td rowspan="2" class="attname">style</td>
                        <td><a href="chapter2-d.html#type.string"><em>string</em></a></td>
                        <td><em>none</em></td>
                     </tr>
                     <tr>
                        <td colspan="2" class="attdesc">
                           Associates style information with the element for use with
                           <a href="appendixh-d.html#XSLT">[XSLT]</a> and <a href="appendixh-d.html#CSS21">[CSS21]</a>.
                           This typically would be an inline CSS style,
                           but this is not specified by MathML.
                           See <a href="chapter6-d.html#world-int-style">Section&nbsp;6.5 Using CSS with MathML</a> for discussion of the interaction
                           of MathML and CSS.
                        </td>
                     </tr>
                     <tr>
                        <td rowspan="2" class="attname">href</td>
                        <td><a href="chapter2-d.html#type.uri"><em>URI</em></a></td>
                        <td><em>none</em></td>
                     </tr>
                     <tr>
                        <td colspan="2" class="attdesc">
                           Can be used to establish the element as a hyperlink to the specfied <em>URI</em>.
                           
                        </td>
                     </tr>
                  </tbody>
               </table>
               <p>Note that MathML 2 had no direct support for linking, and instead
                  followed the W3C Recommendation "XML Linking Language"
                  <a href="appendixh-d.html#XLink">[XLink]</a> in defining links using the
                  <code>xlink:href</code> attribute.  This has changed, and MathML 3 now
                  uses an <code>href</code> attribute.  However, particular compound
                  document formats may specify the use of XML linking with MathML
                  elements, so user agents that support XML linking should continue to
                  support the use of the <code>xlink:href</code> attribute with MathML 3
                  as well.
               </p>
               <p>See also <a href="chapter3-d.html#presm.commatt">Section&nbsp;3.2.2 Mathematics style attributes common to token elements</a> for a list of MathML attributes
                  which can be used on most presentation token elements.
                  
               </p>
               <p>The attribute <code>other</code>,
                  is <a href="chapter2-d.html#interf.deprec">deprecated</a> 
                  (<a href="chapter2-d.html#interf.unspecified">Section&nbsp;2.3.3 Attributes for unspecified data</a>) in favor of the use of 
                  attributes from other namespaces.
                  
               </p>
               <table border="1" class="attributes">
                  <thead>
                     <tr>
                        <th>Name</th>
                        <th>values</th>
                        <th>default</th>
                     </tr>
                  </thead>
                  <tbody>
                     <tr>
                        <td rowspan="2" class="attname">other</td>
                        <td><a href="chapter2-d.html#type.string"><em>string</em></a></td>
                        <td><em>none</em></td>
                     </tr>
                     <tr>
                        <td colspan="2" class="attdesc">
                           DEPRECATED but in MathML 1.0.
                           
                        </td>
                     </tr>
                  </tbody>
               </table>
            </div>
            <div class="div3">
               
               <h3><a name="fund.collapse" id="fund.collapse"></a>2.1.7 Collapsing Whitespace in Input
               </h3>
               <p>In MathML, as in XML, "whitespace" means simple spaces,
                  tabs, newlines, or carriage returns, i.e.,  characters with hexadecimal
                  Unicode codes U+0020, U+0009, U+000A, or
                  U+000D, respectively; see also the discussion of whitespace in Section 2.3 of
                  <a href="appendixg-d.html#XML">[XML]</a>.
               </p>
               <p>MathML ignores whitespace occurring outside token elements.
                  Non-whitespace characters are not allowed there. Whitespace occurring
                  within the content of token elements , except for <a href="chapter4-d.html#contm.cs"><code>&lt;cs&gt;</code></a>, is normalized as follows. All whitespace at the beginning and end of the content is
                  removed, and whitespace internal to content of the element is
                  collapsed canonically, i.e.,  each sequence of 1 or more
                  whitespace characters is replaced with one space character (U+0020, sometimes
                  called a blank character).
               </p>
               <p>For example, <code>&lt;mo&gt; ( &lt;/mo&gt;</code> is equivalent to
                  <code>&lt;mo&gt;(&lt;/mo&gt;</code>, and
                  
               </p><pre class="mathml">
&lt;mtext&gt;
  Theorem
  1:
&lt;/mtext&gt;
</pre><p>
                  is equivalent to 
                  <code>&lt;mtext&gt;Theorem 1:&lt;/mtext&gt;</code>
                  or
                  <code>&lt;mtext&gt;Theorem&amp;#x20;1:&lt;/mtext&gt;</code>.
               </p>
               <p>Authors wishing to encode white space characters at the start or end of
                  the content of a token, or in sequences other than a single space, without
                  having them ignored, must use <code>&amp;nbsp;</code> (U+00A0)
                  or other non-marking characters that are not trimmed.
                  For example, compare the above use of an <code>mtext</code> element 
                  with
                  
               </p><pre class="mathml">
&lt;mtext&gt;
&amp;#xA0;<span style="color:#999900">&lt;!--NO-BREAK SPACE--&gt;</span>Theorem &amp;#xA0;<span style="color:#999900">&lt;!--NO-BREAK SPACE--&gt;</span>1: 
&lt;/mtext&gt; </pre><p>When the first example is rendered, there is nothing before
                  "Theorem", one Unicode space character between "Theorem" and
                  "1:", and nothing after "1:". In the
                  second example, a single space character is to be rendered before
                  "Theorem"; two spaces, one a Unicode space character and 
                  one a Unicode no-break space character, are to be rendered before
                  "1:"; and there is nothing after the
                  "1:".
               </p>
               <p>Note that the value of the <code>xml:space</code> attribute is not relevant
                  in this situation since XML processors pass whitespace in tokens to a
                  MathML processor; it is the requirements of MathML processing which specify that
                  whitespace is trimmed and collapsed.
               </p>
               <p>For whitespace occurring outside the content of the token elements 
                  <code>mi</code>, <code>mn</code>, <code>mo</code>, <code>ms</code>, <code>mtext</code>, 
                  <code>ci</code>, <code>cn</code>, <code>cs</code>, <code>csymbol</code> and <code>annotation</code>,
                  an <code>mspace</code> element should be used, as opposed to an <code>mtext</code> element containing 
                  only whitespace entities.
               </p>
            </div>
         </div>
         <div class="div2">
            
            <h2><a name="interf.toplevel" id="interf.toplevel"></a>2.2 The Top-Level 
               <code>math</code> Element
            </h2>
            <p>MathML specifies a single top-level or root <code>math</code> element, 
               which encapsulates each instance of
               MathML markup within a document.  All other MathML content must be
               contained in a <code>math</code> element; in other words,
               every valid MathML expression is wrapped in outer
               <code>&lt;math&gt;</code> tags. The <code>math</code>
               element must always be the outermost element in a MathML expression;
               it is an error for one <code>math</code> element to contain
               another.  These considerations also apply when sub-expressions are
               passed between applications, such as for cut-and-paste operations;
               See <a href="chapter6-d.html#world-int-transfers">Section&nbsp;6.3 Transferring MathML</a>.
            </p>
            <p>The <code>math</code> element can contain an arbitrary number
               of child elements. They render by default as if they
               were contained in an <code>mrow</code> element.
            </p>
            <div class="div3">
               
               <h3><a name="interf.toplevel.atts" id="interf.toplevel.atts"></a>2.2.1 Attributes
               </h3>
               <p>The <code>math</code> element accepts any of the attributes that can be set on
                  <a href="chapter3-d.html#presm.mstyle">Section&nbsp;3.3.4 Style Change <code>&lt;mstyle&gt;</code></a>, including the common attributes 
                  specified in <a href="chapter2-d.html#fund.globatt">Section&nbsp;2.1.6 Attributes Shared by all MathML Elements</a>.
                  In particular, it accepts the <code>dir</code> attribute for
                  setting the overall directionality; the <code>math</code> element is usually
                  the most useful place to specify the directionality
                  (See <a href="chapter3-d.html#presm.bidi">Section&nbsp;3.1.5 Directionality</a> for further discussion).
                  Note that the <code>dir</code> attribute defaults to "ltr"
                  on the <code>math</code> element (but <em>inherits</em> on all other elements
                  which accept the <code>dir</code> attribute); this provides for backward
                  compatibility with MathML 2.0 which had no notion of directionality.
                  Also, it accepts the <code>mathbackground</code> attribute in the same sense
                  as <code>mstyle</code> and other presentation elements to set the background
                  color of the bounding box, rather than specifying a default for the attribute
                  (see <a href="chapter3-d.html#presm.presatt">Section&nbsp;3.1.10 Mathematics style attributes common to presentation elements</a>)
               </p>
               <p>In addition to those attributes, the <code>math</code> element accepts:
               </p>
               <table border="1" class="attributes">
                  <thead>
                     <tr>
                        <th>Name</th>
                        <th>values</th>
                        <th>default</th>
                     </tr>
                  </thead>
                  <tbody>
                     <tr>
                        <td rowspan="2" class="attname">display</td>
                        <td>"block" | "inline"</td>
                        <td>inline</td>
                     </tr>
                     <tr>
                        <td colspan="2" class="attdesc">
                           specifies whether the enclosed MathML expression should be rendered
                           as a separate vertical block (in display style)
                           or inline, aligned with adjacent text.
                           When <code>display</code>="block", <code>displaystyle</code> is initialized 
                           to "true",
                           whereas when <code>display</code>="inline", <code>displaystyle</code> 
                           is initialized to "false";
                           in both cases <code>scriptlevel</code> is initialized to 0
                           (See <a href="chapter3-d.html#presm.scriptlevel">Section&nbsp;3.1.6 Displaystyle and Scriptlevel</a>).
                           Moreover, when the math element is embedded in a larger document,
                           a block math element should be treated as a block element as appropriate
                           for the document type (typically as a new vertical block),
                           whereas an inline math element should be treated as inline
                           (typically exactly as if it were a sequence of words in normal text).
                           In particular, this applies to spacing and linebreaking: for instance,
                           there should not be spaces or line breaks inserted between inline math
                           and any immediately following punctuation.
                           When the display attribute is missing, a rendering agent is free to initialize
                           as appropriate to the context.
                           
                        </td>
                     </tr>
                     <tr>
                        <td rowspan="2" class="attname">maxwidth</td>
                        <td><a href="chapter2-d.html#type.length"><em>length</em></a></td>
                        <td><em>available width</em></td>
                     </tr>
                     <tr>
                        <td colspan="2" class="attdesc">
                           specifies the maximum width to be used for linebreaking.
                           The default is the maximum width available in the surrounding environment.
                           If that value cannot be determined, the renderer should assume an infinite rendering width.
                           
                        </td>
                     </tr>
                     <tr>
                        <td rowspan="2" class="attname">overflow</td>
                        <td>"linebreak" | "scroll" | "elide" | "truncate" | "scale"</td>
                        <td>linebreak</td>
                     </tr>
                     <tr>
                        <td colspan="2" class="attdesc">
                           specifies the preferred handing in cases where an expression is too long to
                           fit in the allowed width. See the discussion below.
                           
                        </td>
                     </tr>
                     <tr>
                        <td rowspan="2" class="attname">altimg</td>
                        <td><a href="chapter2-d.html#type.uri"><em>URI</em></a></td>
                        <td><em>none</em></td>
                     </tr>
                     <tr>
                        <td colspan="2" class="attdesc">
                           provides a URI referring to an image to display as a fall-back
                           for user agents that do not support embedded MathML. 
                           
                        </td>
                     </tr>
                     <tr>
                        <td rowspan="2" class="attname">altimg-width</td>
                        <td><a href="chapter2-d.html#type.length"><em>length</em></a></td>
                        <td><em>width of </em><code>altimg</code></td>
                     </tr>
                     <tr>
                        <td colspan="2" class="attdesc">
                           specifies the width to display <code>altimg</code>, scaling the image if necessary;
                           See <code>altimg-height</code>.
                           
                        </td>
                     </tr>
                     <tr>
                        <td rowspan="2" class="attname">altimg-height</td>
                        <td><a href="chapter2-d.html#type.length"><em>length</em></a></td>
                        <td><em>height of </em><code>altimg</code></td>
                     </tr>
                     <tr>
                        <td colspan="2" class="attdesc">
                           specifies the height to display <code>altimg</code>, scaling the image if necessary;
                           if only one of the attributes <code>altimg-width</code> and <code>altimg-height</code>
                           are given, the scaling should preserve the image's aspect ratio;
                           if neither attribute is given, the image should be shown at its natural size.
                           
                        </td>
                     </tr>
                     <tr>
                        <td rowspan="2" class="attname">altimg-valign</td>
                        <td><a href="chapter2-d.html#type.length"><em>length</em></a>
                           | "top" | "middle" | "bottom" 
                        </td>
                        <td>0ex</td>
                     </tr>
                     <tr>
                        <td colspan="2" class="attdesc">
                           specifies the vertical alignment of the image with respect to adjacent inline material.
                           A positive value of <code>altimg-valign</code> shifts the bottom of the image above the
                           current baseline, while a negative value lowers it.
                           The keyword "top" aligns the top of the image with the top of adjacent inline material;
                           "center" aligns the middle of the image to the middle of adjacent material;
                           "bottom" aligns the bottom of the image to the bottom of adjacent material
                           (not necessarily the baseline). This attribute only has effect
                           when <code>display</code>="inline".
                           By default, the bottom of the image aligns to the baseline. 
                           
                        </td>
                     </tr>
                     <tr>
                        <td rowspan="2" class="attname">alttext</td>
                        <td><a href="chapter2-d.html#type.string"><em>string</em></a></td>
                        <td><em>none</em></td>
                     </tr>
                     <tr>
                        <td colspan="2" class="attdesc">
                           provides a textual alternative as a fall-back for user agents
                           that do not support embedded MathML or images.
                           
                        </td>
                     </tr>
                     <tr>
                        <td rowspan="2" class="attname">cdgroup</td>
                        <td><a href="chapter2-d.html#type.uri"><em>URI</em></a></td>
                        <td><em>none</em></td>
                     </tr>
                     <tr>
                        <td colspan="2" class="attdesc">
                           specifies a CD group file that acts as a catalogue of CD bases for locating
                           OpenMath content dictionaries of <code>csymbol</code>, <code>annotation</code>, and
                           <code>annotation-xml</code> elements in this <code>math</code> element; see <a href="chapter4-d.html#contm.csymbol">Section&nbsp;4.2.3 Content Symbols <code>&lt;csymbol&gt;</code></a>. When no <code>cdgroup</code> attribute is explicitly specified, the
                           document format embedding this <code>math</code> element may provide a method for determining
                           CD bases. Otherwise the system must determine a CD base; in the absence of specific
                           information <code>http://www.openmath.org/cd</code> is assumed as the CD base for all
                           <code>csymbol</code>, <code>annotation</code>, and <code>annotation-xml</code> elements.  This is the
                           CD base for the collection of standard CDs maintained by the OpenMath Society.
                           
                        </td>
                     </tr>
                  </tbody>
               </table>
               <p>In cases where size negotiation is not possible or fails
                  (for example in the case of an expression that is too long to fit in the allowed width),
                  the <code>overflow</code> attribute is provided to suggest a processing method to the renderer.
                  Allowed values are:
               </p>
               <table id="fund.table-overflow" border="1">
                  <thead>
                     <tr>
                        <th> Value   </th>
                        <th> Meaning</th>
                     </tr>
                  </thead>
                  <tbody>
                     <tr>
                        <td>"linebreak"</td>
                        <td>The expression will be broken across several lines.
                           See <a href="chapter3-d.html#presm.linebreaking">Section&nbsp;3.1.7 Linebreaking of Expressions</a> for further discussion.
                           
                        </td>
                     </tr>
                     <tr>
                        <td>"scroll"</td>
                        <td>The window provides a viewport
                           into the larger complete display of the mathematical
                           expression. Horizontal or vertical scroll bars are added to the window
                           as necessary to allow the viewport to be moved to a different
                           position.
                        </td>
                     </tr>
                     <tr>
                        <td>"elide"</td>
                        <td>The display is abbreviated by removing enough of it so that
                           the remainder fits into the window. For example, a large polynomial
                           might have the first and last terms displayed with "+ ... +" 
                           between
                           them. Advanced renderers may provide a facility to zoom in on elided
                           areas.
                           
                        </td>
                     </tr>
                     <tr>
                        <td>"truncate"</td>
                        <td>The display is abbreviated by simply truncating it at the right and
                           bottom borders. It is recommended that some indication of truncation is
                           made to the viewer.
                        </td>
                     </tr>
                     <tr>
                        <td>"scale"</td>
                        <td>The fonts used to display the mathematical expression are
                           chosen so that the full expression fits in the window. Note that this
                           only happens if the expression is too large. In the case of a window
                           larger than necessary, the expression is shown at its normal size
                           within the larger window.
                        </td>
                     </tr>
                  </tbody>
               </table>
            </div>
            <div class="div3">
               
               <h3><a name="id.2.2.2" id="id.2.2.2"></a>2.2.2 Deprecated Attributes
               </h3>
               <p>The following attributes of <code>math</code> are deprecated:
               </p>
               <table border="1" class="attributes">
                  <thead>
                     <tr>
                        <th>Name</th>
                        <th>values</th>
                        <th>default</th>
                     </tr>
                  </thead>
                  <tbody>
                     <tr>
                        <td rowspan="2" class="attname">macros</td>
                        <td><a href="chapter2-d.html#type.uri"><em>URI</em></a> *
                        </td>
                        <td><em>none</em></td>
                     </tr>
                     <tr>
                        <td colspan="2" class="attdesc">
                           intended to provide a way of pointing to external macro definition files.
                           Macros are not part of the MathML specification.
                           
                        </td>
                     </tr>
                     <tr>
                        <td rowspan="2" class="attname">mode</td>
                        <td>"display" | "inline"</td>
                        <td>inline</td>
                     </tr>
                     <tr>
                        <td colspan="2" class="attdesc">
                           specified whether the enclosed MathML expression should be rendered in
                           a display style or an inline style.
                           This attribute is <a href="chapter2-d.html#interf.deprec">deprecated</a> in
                           favor of the <code>display</code> attribute.
                           
                        </td>
                     </tr>
                  </tbody>
               </table>
            </div>
         </div>
         <div class="div2">
            
            <h2><a name="interf.genproc" id="interf.genproc"></a>2.3 Conformance
            </h2>
            <p>Information nowadays is commonly 
               generated, processed and rendered by
               software tools. The exponential growth of the Web is fueling the
               development of advanced systems for automatically searching,
               categorizing, and interconnecting information. 
               In addition, there are increasing numbers of
               Web services, some of which offer technically based materials
               and activities. Thus, although MathML
               can be written by hand and read by humans,
               whether machine-aided or just with much concentration, 
               the future of MathML is
               largely tied to the ability to process it with software tools.
            </p>
            <p>There are many different kinds of MathML 
               processors: editors for authoring MathML expressions, translators for
               converting to and from other encodings, validators for checking MathML
               expressions, computation engines that evaluate, manipulate, or compare
               MathML expressions, and rendering engines that produce visual, aural,
               or tactile representations of mathematical notation.  What it
               means to support MathML varies widely between applications.  For
               example, the issues that arise with a  validating
               parser are very different from those for an equation
               editor.
            </p>
            <p>This section gives guidelines that describe different types
               of MathML support and make clear the extent of MathML support in
               a given application.  Developers, users, and reviewers are encouraged
               to use these guidelines in characterizing products.  The intention
               behind these guidelines is to facilitate reuse by
               and interoperability
               of MathML applications by accurately setting out their
               capabilities in quantifiable terms.
            </p>
            <p>The W3C Math Working Group maintains <a href="http://www.w3.org/Math/iandi/compliance">MathML Compliance
                  Guidelines</a>.  Consult this document for future updates on 
               conformance activities and resources.
               
            </p>
            <div class="div3">
               
               <h3><a name="fund.mathmlconf" id="fund.mathmlconf"></a>2.3.1 MathML Conformance
               </h3>
               <p>A valid MathML expression is an XML construct determined by the MathML
                  RelaxNG Schema together with the additional requirements given in this specification.
               </p>
               <p>We shall use the phrase "a MathML processor" 
                  to mean any application that
                  can accept or produce a valid MathML
                  expression.  A MathML processor that both accepts and produces valid 
                  MathML expressions may be able to "round-trip" MathML.
                  Perhaps the simplest example of an 
                  application that might round-trip a MathML
                  expression would be an editor that writes it to a new file without
                  modifications.
               </p>
               <p>Three forms of MathML conformance are specified:
                  
               </p>
               <ol type="1">
                  <li>
                     <p>A MathML-input-conformant processor must
                        accept all valid MathML expressions; it should appropriately translate all
                        MathML expressions into application-specific form allowing native
                        application operations to be performed.
                     </p>
                  </li>
                  <li>
                     <p>A MathML-output-conformant processor must
                        generate valid MathML, appropriately representing all
                        application-specific data.
                     </p>
                  </li>
                  <li>
                     <p>A MathML-round-trip-conformant processor must
                        preserve MathML equivalence. Two MathML expressions are
                        "equivalent" if and only if both expressions have the
                        same interpretation (as stated by the MathML 
                        Schema and  specification)
                        under any relevant circumstances, by any MathML processor. Equivalence on an
                        element-by-element basis is discussed elsewhere in this document.
                     </p>
                  </li>
               </ol>
               <p>Beyond the above definitions, the MathML specification makes no
                  demands of individual processors.  In order to guide developers, the
                  MathML specification includes advisory material; for example, there
                  are many recommended rendering rules throughout <a href="chapter3-d.html">Chapter&nbsp;3 Presentation Markup</a>. 
                  However, in general, developers are given wide latitude to
                  interpret what kind of MathML implementation is meaningful for
                  their own particular application.
               </p>
               <p>To clarify the difference between conformance and
                  interpretation of what is meaningful, consider some examples:
                  
               </p>
               <ol type="1">
                  <li>
                     <p>In order 
                        to be MathML-input-conformant, a
                        validating parser needs only to accept expressions, and return
                        "true" for expressions that are valid MathML. In
                        particular, it need not render or interpret the MathML expressions at
                        all.
                     </p>
                  </li>
                  <li>
                     <p>A MathML computer-algebra interface based on content markup
                        might choose to ignore all presentation markup. Provided the interface
                        accepts all valid MathML expressions including those containing
                        presentation markup, it would be technically correct to characterize
                        the application as MathML-input-conformant.
                     </p>
                  </li>
                  <li>
                     <p>An equation editor might have an internal data representation
                        that makes it easy to export some equations as MathML but not
                        others. If the editor exports the simple equations as valid MathML,
                        and merely displays an error message to the effect that conversion
                        failed for the others, it is still technically
                        MathML-output-conformant.
                     </p>
                  </li>
               </ol>
               <div class="div4">
                  
                  <h4><a name="interf.testsuite" id="interf.testsuite"></a>2.3.1.1 MathML Test Suite and Validator
                  </h4>
                  <p>As the previous examples show, to be useful, the concept of MathML
                     conformance frequently involves a judgment about what parts of the
                     language are meaningfully implemented, as opposed to parts that are
                     merely processed in a technically correct way with respect to the
                     definitions of conformance.  This requires some mechanism for giving a
                     quantitative statement about which parts of MathML are meaningfully
                     implemented by a given application.  To this end, the W3C Math Working
                     Group has provided a <a href="http://www.w3.org/Math/testsuite/">test
                        suite</a>.
                  </p>
                  <p>The test suite consists of a large number of MathML expressions
                     categorized by markup category and dominant MathML element being
                     tested.  The existence of this test suite makes it possible, for example,
                     to characterize quantitatively the hypothetical computer algebra interface
                     mentioned above by saying that it is a MathML-input-conformant processor
                     which meaningfully implements MathML content markup, including all of
                     the expressions in the content markup section of the test suite.
                  </p>
                  <p>Developers who choose not to implement parts of the MathML
                     specification in a meaningful way are encouraged to itemize the parts
                     they leave out by referring to specific categories in the test suite.
                  </p>
                  <p>For MathML-output-conformant processors, information about currently 
                     available tools to validate MathML is
                     maintained at the <a href="http://www.w3.org/Math/validator/">W3C MathML Validator</a>. 
                     Developers of MathML-output-conformant processors are encouraged to verify 
                     their output using this
                     validator.
                  </p>
                  <p>Customers of MathML applications who wish to verify claims as to which
                     parts of the MathML specification are implemented by an application are
                     encouraged to use the test suites as a part of their decision
                     processes.
                  </p>
               </div>
               <div class="div4">
                  
                  <h4><a name="interf.deprec" id="interf.deprec"></a>2.3.1.2 Deprecated MathML 1.x and MathML 2.x Features
                  </h4>
                  <p>MathML 3.0 contains a number of features of earlier MathML
                     which are now deprecated.  The following points define what it means for a
                     feature to be deprecated, and clarify the relation between
                     deprecated features and  current MathML conformance.
                  </p>
                  <ol type="1">
                     <li>
                        <p>In order to be MathML-output-conformant, authoring tools may not
                           generate MathML markup containing deprecated features.
                        </p>
                     </li>
                     <li>
                        <p>In order to be MathML-input-conformant, rendering and reading
                           tools must support deprecated features if they are to be 
                           in conformance with MathML 1.x or MathML 2.x.   They do not have to support deprecated
                           features to be considered in conformance with MathML 3.0.  However, all tools
                           are encouraged to support the old forms as much as
                           possible.
                        </p>
                     </li>
                     <li>
                        <p>In order to be MathML-round-trip-conformant, a processor need
                           only preserve MathML equivalence on expressions containing no
                           deprecated features.
                        </p>
                     </li>
                  </ol>
               </div>
               <div class="div4">
                  
                  <h4><a name="interf.extension" id="interf.extension"></a>2.3.1.3 MathML 
                     Extension Mechanisms and Conformance
                  </h4>
                  <p>MathML 3.0 defines three basic extension mechanisms:  the <code>mglyph</code>
                     element provides a way of displaying glyphs for non-Unicode
                     characters, and glyph variants for existing Unicode characters; the
                     <code>maction</code> element uses attributes from other namespaces to obtain
                     implementation-specific parameters; and content markup makes use of
                     the <code>definitionURL</code> attribute, as well as
                     Content Dictionaries and the <code>cd</code> attribute, to point to external
                     definitions of mathematical semantics.
                  </p>
                  <p>These extension mechanisms are important because they provide a way
                     of encoding concepts that are beyond the scope of MathML 3.0 as presently 
                     explicitly specified, which
                     allows MathML to be used for exploring new ideas not yet susceptible
                     to standardization.  However, as new ideas take hold, they may become
                     part of future standards.  For example, an emerging character that
                     must be represented by an <code>mglyph</code> element today may be
                     assigned a Unicode code point in the future. At that time,
                     representing the character directly by its Unicode code point would be
                     preferable.  This transition into Unicode has
                     already taken place for hundreds of characters used for mathematics.
                  </p>
                  <p>Because the possibility of future obsolescence is inherent in the
                     use of extension mechanisms to facilitate the discussion of new ideas,
                     MathML can reasonably make 
                     no conformance requirements concerning the use of
                     extension mechanisms, even when alternative standard markup is
                     available.  For example, using an <code>mglyph</code> element to represent
                     an 'x' is permitted.  However, authors and implementers are
                     strongly encouraged to use standard markup whenever possible.
                     Similarly, maintainers of documents employing MathML 3.0 extension
                     mechanisms are encouraged to monitor relevant standards activity
                     (e.g., Unicode, OpenMath, etc.) and to update documents as more
                     standardized markup becomes available.
                  </p>
               </div>
            </div>
            <div class="div3">
               
               <h3><a name="interf.error" id="interf.error"></a>2.3.2 Handling of Errors
               </h3>
               <p>If a MathML-input-conformant application receives
                  input containing one or more elements with an illegal number or type
                  of attributes or child schemata, it should nonetheless attempt to
                  render all the input in an intelligible way, i.e., to render normally
                  those parts of the input that were valid, and to render error messages
                  (rendered as if enclosed in an <a href="chapter3-d.html#presm.merror"><code>merror</code></a> element) in place of
                  invalid expressions.
               </p>
               <p>MathML-output-conformant applications such as
                  editors and translators may choose to generate <code>merror</code>
                  expressions to signal errors in their input. This is usually
                  preferable to generating valid, but possibly erroneous, MathML.
               </p>
            </div>
            <div class="div3">
               
               <h3><a name="interf.unspecified" id="interf.unspecified"></a>2.3.3 Attributes for unspecified data
               </h3>
               <p>The MathML attributes described in the MathML specification are
                  intended to allow for good presentation and content markup. However
                  it is never possible to cover all users' needs for markup. Ideally, the MathML
                  attributes should be an open-ended list so that users can add specific
                  attributes for specific renderers. However, this cannot be done within
                  the confines of a single XML DTD or in a Schema. 
                  Although it can be done using extensions of the standard DTD, say,
                  some authors will wish to use non-standard
                  attributes to take advantage of renderer-specific capabilities while
                  remaining strictly in conformance with the standard
                  DTD.
               </p>
               <p>To allow this, the MathML 1.0 specification <a href="appendixh-d.html#MathML1">[MathML1]</a>
                  allowed the attribute <code>other</code> on all elements, for use as a hook to pass
                  on renderer-specific information. In particular, it was intended as a hook for
                  passing information to audio renderers, computer algebra systems, and for pattern
                  matching in future macro/extension mechanisms. The motivation for this approach to
                  the problem was historical, looking to PostScript, for example, where comments are
                  widely used to pass information that is not part of PostScript.
               </p>
               <p>In the next period of evolution of MathML the
                  development of a general XML namespace mechanism
                  seemed to make the use of the <code>other</code>
                  attribute obsolete.  In MathML 2.0, the <code>other</code> attribute is
                  <a href="chapter2-d.html#interf.deprec">deprecated</a> in favor of the use of
                  namespace prefixes to identify non-MathML attributes.  The 
                  <code>other</code> attribute remains deprecated in MathML 3.0.
               </p>
               <p>For example, in MathML 1.0, it was recommended that if additional information
                  was used in a renderer-specific implementation for the <code>maction</code> element 
                  (<a href="chapter3-d.html#presm.maction">Section&nbsp;3.7.1 Bind Action to Sub-Expression
                     <code>&lt;maction&gt;</code></a>),
                  that information should be passed in using the <code>other</code> attribute:
               </p><pre>
&lt;maction actiontype="highlight" other="color='#ff0000'"&gt; expression &lt;/maction&gt;
</pre><p>From MathML 2.0 onwards, a <code>color</code> 
                  attribute from another namespace would be used:
               </p><pre>
&lt;body xmlns:my="http://www.example.com/MathML/extensions"&gt;
...
&lt;maction actiontype="highlight" my:color="#ff0000"&gt; expression &lt;/maction&gt;
...
&lt;/body&gt;
</pre><p>Note that the intent of allowing non-standard attributes is
                  <em>not</em> to encourage software developers to use this as a
                  loophole for circumventing the core conventions for MathML markup. 
                  Authors and applications should use non-standard attributes
                  judiciously.
               </p>
            </div>
         </div>
      </div>
      <div class="minitoc">
         
         Overview: <a href="Overview-d.html">Mathematical Markup Language (MathML) Version 3.0</a><br>
         Previous:     1 <a href="chapter1-d.html">Introduction</a><br>
         Next:     3 <a href="chapter3-d.html">Presentation Markup</a></div>
   </body>
</html>