RubyGems - mml - Versions diffs - 2.3.0 → 2.3.2 - Mend

mml 2.3.0 → 2.3.2

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (336) hide show

checksums.yaml +4 -4
data/.gitmodules +9 -0
data/.rubocop.yml +4 -0
data/.rubocop_todo.yml +83 -18
data/Gemfile +0 -2
data/README.adoc +176 -47
data/Rakefile +16 -1
data/lib/mml/base/common_attributes.rb +44 -0
data/lib/mml/base/content/annotation.rb +28 -0
data/lib/mml/base/content/annotation_xml.rb +31 -0
data/lib/mml/base/content/apply.rb +27 -0
data/lib/mml/base/content/arith.rb +243 -0
data/lib/mml/base/content/bind.rb +27 -0
data/lib/mml/base/content/bvar.rb +20 -0
data/lib/mml/base/content/calculus.rb +103 -0
data/lib/mml/base/content/cbytes.rb +24 -0
data/lib/mml/base/content/cerror.rb +24 -0
data/lib/mml/base/content/ci.rb +77 -0
data/lib/mml/base/content/cn.rb +33 -0
data/lib/mml/base/content/condition.rb +20 -0
data/lib/mml/base/content/constants.rb +173 -0
data/lib/mml/base/content/cs.rb +22 -0
data/lib/mml/base/content/csymbol.rb +79 -0
data/lib/mml/base/content/declare.rb +34 -0
data/lib/mml/base/content/degree.rb +20 -0
data/lib/mml/base/content/elementary_functions.rb +309 -0
data/lib/mml/base/content/fn.rb +25 -0
data/lib/mml/base/content/functions.rb +85 -0
data/lib/mml/base/content/interval.rb +24 -0
data/lib/mml/base/content/inverse.rb +25 -0
data/lib/mml/base/content/lambda.rb +20 -0
data/lib/mml/base/content/linear_algebra.rb +122 -0
data/lib/mml/base/content/logic.rb +93 -0
data/lib/mml/base/content/otherwise.rb +20 -0
data/lib/mml/base/content/piece.rb +20 -0
data/lib/mml/base/content/piecewise.rb +20 -0
data/lib/mml/base/content/relations.rb +113 -0
data/lib/mml/base/content/reln.rb +19 -0
data/lib/mml/base/content/semantics.rb +27 -0
data/lib/mml/base/content/sep.rb +19 -0
data/lib/mml/base/content/sets.rb +163 -0
data/lib/mml/base/content/share.rb +22 -0
data/lib/mml/base/content/statistics.rb +95 -0
data/lib/mml/base/content/vector_calculus.rb +63 -0
data/lib/mml/base/content_loader.rb +195 -0
data/lib/mml/base/maction.rb +1 -0
data/lib/mml/base/math.rb +47 -0
data/lib/mml/base/menclose.rb +1 -1
data/lib/mml/base/mfenced.rb +2 -2
data/lib/mml/base/mglyph.rb +2 -2
data/lib/mml/base/mi.rb +9 -6
data/lib/mml/base/mlabeledtr.rb +2 -6
data/lib/mml/base/mn.rb +3 -2
data/lib/mml/base/mo.rb +3 -3
data/lib/mml/base/mrow.rb +0 -2
data/lib/mml/base/ms.rb +4 -6
data/lib/mml/base/mscarries.rb +1 -1
data/lib/mml/base/mspace.rb +0 -2
data/lib/mml/base/mstyle.rb +4 -8
data/lib/mml/base/mtable.rb +8 -0
data/lib/mml/base/mtd.rb +6 -0
data/lib/mml/base/mtext.rb +0 -2
data/lib/mml/base/semantics.rb +4 -2
data/lib/mml/base/universal_presentation_attributes.rb +46 -0
data/lib/mml/base/v3_common.rb +16 -0
data/lib/mml/base/v3_presentation_attributes.rb +15 -0
data/lib/mml/base/v4_attributes.rb +4 -18
data/lib/mml/base.rb +11 -0
data/lib/mml/common_elements.rb +336 -0
data/lib/mml/context_configuration.rb +29 -0
data/lib/mml/v2/annotation.rb +9 -0
data/lib/mml/v2/annotation_xml.rb +9 -0
data/lib/mml/v2/apply.rb +9 -0
data/lib/mml/v2/arith.rb +93 -0
data/lib/mml/v2/bind.rb +9 -0
data/lib/mml/v2/bvar.rb +9 -0
data/lib/mml/v2/calculus.rb +33 -0
data/lib/mml/v2/ci.rb +9 -0
data/lib/mml/v2/cn.rb +9 -0
data/lib/mml/v2/common_elements.rb +34 -0
data/lib/mml/v2/condition.rb +9 -0
data/lib/mml/v2/configuration.rb +13 -0
data/lib/mml/v2/constants.rb +65 -0
data/lib/mml/v2/csymbol.rb +9 -0
data/lib/mml/v2/degree.rb +9 -0
data/lib/mml/v2/elementary_functions.rb +121 -0
data/lib/mml/v2/fn.rb +9 -0
data/lib/mml/v2/functions.rb +29 -0
data/lib/mml/v2/interval.rb +9 -0
data/lib/mml/v2/inverse.rb +9 -0
data/lib/mml/v2/lambda.rb +9 -0
data/lib/mml/v2/linear_algebra.rb +41 -0
data/lib/mml/v2/logic.rb +33 -0
data/lib/mml/v2/maction.rb +9 -0
data/lib/mml/v2/maligngroup.rb +9 -0
data/lib/mml/v2/malignmark.rb +9 -0
data/lib/mml/v2/math.rb +11 -0
data/lib/mml/v2/menclose.rb +9 -0
data/lib/mml/v2/merror.rb +9 -0
data/lib/mml/v2/mfenced.rb +9 -0
data/lib/mml/v2/mfrac.rb +9 -0
data/lib/mml/v2/mfraction.rb +9 -0
data/lib/mml/v2/mglyph.rb +9 -0
data/lib/mml/v2/mi.rb +9 -0
data/lib/mml/v2/mlabeledtr.rb +9 -0
data/lib/mml/v2/mlongdiv.rb +9 -0
data/lib/mml/v2/mmultiscripts.rb +9 -0
data/lib/mml/v2/mn.rb +9 -0
data/lib/mml/v2/mo.rb +10 -0
data/lib/mml/v2/mover.rb +9 -0
data/lib/mml/v2/mpadded.rb +9 -0
data/lib/mml/v2/mphantom.rb +9 -0
data/lib/mml/v2/mprescripts.rb +9 -0
data/lib/mml/v2/mroot.rb +9 -0
data/lib/mml/v2/mrow.rb +9 -0
data/lib/mml/v2/ms.rb +9 -0
data/lib/mml/v2/mscarries.rb +9 -0
data/lib/mml/v2/mscarry.rb +9 -0
data/lib/mml/v2/msgroup.rb +9 -0
data/lib/mml/v2/msline.rb +9 -0
data/lib/mml/v2/mspace.rb +9 -0
data/lib/mml/v2/msqrt.rb +9 -0
data/lib/mml/v2/msrow.rb +9 -0
data/lib/mml/v2/mstack.rb +9 -0
data/lib/mml/v2/mstyle.rb +10 -0
data/lib/mml/v2/msub.rb +9 -0
data/lib/mml/v2/msubsup.rb +9 -0
data/lib/mml/v2/msup.rb +9 -0
data/lib/mml/v2/mtable.rb +9 -0
data/lib/mml/v2/mtd.rb +9 -0
data/lib/mml/v2/mtext.rb +9 -0
data/lib/mml/v2/mtr.rb +9 -0
data/lib/mml/v2/munder.rb +9 -0
data/lib/mml/v2/munderover.rb +9 -0
data/lib/mml/v2/namespace.rb +7 -0
data/lib/mml/v2/none.rb +9 -0
data/lib/mml/v2/otherwise.rb +9 -0
data/lib/mml/v2/piece.rb +9 -0
data/lib/mml/v2/piecewise.rb +9 -0
data/lib/mml/v2/relations.rb +41 -0
data/lib/mml/v2/reln.rb +13 -0
data/lib/mml/v2/semantics.rb +9 -0
data/lib/mml/v2/sep.rb +9 -0
data/lib/mml/v2/sets.rb +57 -0
data/lib/mml/v2/statistics.rb +33 -0
data/lib/mml/v2/vector_calculus.rb +21 -0
data/lib/mml/v2.rb +311 -0
data/lib/mml/v3/annotation.rb +10 -0
data/lib/mml/v3/annotation_xml.rb +10 -0
data/lib/mml/v3/apply.rb +10 -0
data/lib/mml/v3/arith.rb +115 -0
data/lib/mml/v3/bind.rb +10 -0
data/lib/mml/v3/calculus.rb +40 -0
data/lib/mml/v3/cbytes.rb +10 -0
data/lib/mml/v3/cerror.rb +10 -0
data/lib/mml/v3/ci.rb +10 -0
data/lib/mml/v3/cn.rb +10 -0
data/lib/mml/v3/common_elements.rb +34 -0
data/lib/mml/v3/constants.rb +80 -0
data/lib/mml/v3/constructs.rb +55 -0
data/lib/mml/v3/cs.rb +10 -0
data/lib/mml/v3/csymbol.rb +10 -0
data/lib/mml/v3/deprecated_content.rb +29 -0
data/lib/mml/v3/elementary_functions.rb +145 -0
data/lib/mml/v3/functions.rb +35 -0
data/lib/mml/v3/linear_algebra.rb +50 -0
data/lib/mml/v3/logic.rb +40 -0
data/lib/mml/v3/maction.rb +1 -1
data/lib/mml/v3/math.rb +7 -1
data/lib/mml/v3/mi.rb +1 -0
data/lib/mml/v3/mn.rb +1 -0
data/lib/mml/v3/mo.rb +1 -0
data/lib/mml/v3/mrow.rb +1 -0
data/lib/mml/v3/ms.rb +1 -0
data/lib/mml/v3/mstyle.rb +1 -0
data/lib/mml/v3/mtext.rb +1 -0
data/lib/mml/v3/relations.rb +50 -0
data/lib/mml/v3/sets.rb +70 -0
data/lib/mml/v3/statistics.rb +40 -0
data/lib/mml/v3/vector_calculus.rb +25 -0
data/lib/mml/v3.rb +25 -0
data/lib/mml/v4/a.rb +4 -3
data/lib/mml/v4/annotation.rb +10 -0
data/lib/mml/v4/annotation_xml.rb +14 -0
data/lib/mml/v4/apply.rb +9 -0
data/lib/mml/v4/arith.rb +93 -0
data/lib/mml/v4/calculus.rb +25 -0
data/lib/mml/v4/cbytes.rb +9 -0
data/lib/mml/v4/cerror.rb +9 -0
data/lib/mml/v4/ci.rb +9 -0
data/lib/mml/v4/cn.rb +9 -0
data/lib/mml/v4/common_elements.rb +33 -0
data/lib/mml/v4/constants.rb +65 -0
data/lib/mml/v4/constructs.rb +49 -0
data/lib/mml/v4/cs.rb +9 -0
data/lib/mml/v4/csymbol.rb +9 -0
data/lib/mml/v4/deprecated_content.rb +25 -0
data/lib/mml/v4/elementary_functions.rb +118 -0
data/lib/mml/v4/factorof.rb +9 -0
data/lib/mml/v4/functions.rb +30 -0
data/lib/mml/v4/limit.rb +9 -0
data/lib/mml/v4/linear_algebra.rb +41 -0
data/lib/mml/v4/logic.rb +33 -0
data/lib/mml/v4/maction.rb +1 -2
data/lib/mml/v4/maligngroup.rb +0 -1
data/lib/mml/v4/malignmark.rb +0 -1
data/lib/mml/v4/math.rb +1 -1
data/lib/mml/v4/menclose.rb +0 -1
data/lib/mml/v4/merror.rb +0 -1
data/lib/mml/v4/mfenced.rb +0 -1
data/lib/mml/v4/mfrac.rb +0 -1
data/lib/mml/v4/mfraction.rb +0 -1
data/lib/mml/v4/mglyph.rb +0 -1
data/lib/mml/v4/mi.rb +1 -1
data/lib/mml/v4/mlabeledtr.rb +0 -1
data/lib/mml/v4/mlongdiv.rb +0 -1
data/lib/mml/v4/mmultiscripts.rb +0 -1
data/lib/mml/v4/mn.rb +1 -1
data/lib/mml/v4/mo.rb +1 -1
data/lib/mml/v4/mover.rb +0 -1
data/lib/mml/v4/mpadded.rb +0 -1
data/lib/mml/v4/mphantom.rb +0 -1
data/lib/mml/v4/mprescripts.rb +0 -1
data/lib/mml/v4/mroot.rb +0 -1
data/lib/mml/v4/mrow.rb +1 -1
data/lib/mml/v4/ms.rb +1 -1
data/lib/mml/v4/mscarries.rb +0 -1
data/lib/mml/v4/mscarry.rb +0 -1
data/lib/mml/v4/msgroup.rb +0 -1
data/lib/mml/v4/msline.rb +0 -1
data/lib/mml/v4/mspace.rb +0 -1
data/lib/mml/v4/msqrt.rb +0 -1
data/lib/mml/v4/msrow.rb +0 -1
data/lib/mml/v4/mstack.rb +0 -1
data/lib/mml/v4/mstyle.rb +1 -1
data/lib/mml/v4/msub.rb +0 -1
data/lib/mml/v4/msubsup.rb +0 -1
data/lib/mml/v4/msup.rb +0 -1
data/lib/mml/v4/mtable.rb +0 -1
data/lib/mml/v4/mtd.rb +0 -1
data/lib/mml/v4/mtext.rb +1 -1
data/lib/mml/v4/mtr.rb +0 -1
data/lib/mml/v4/munder.rb +0 -1
data/lib/mml/v4/munderover.rb +0 -1
data/lib/mml/v4/none.rb +0 -1
data/lib/mml/v4/relations.rb +37 -0
data/lib/mml/v4/semantics.rb +0 -1
data/lib/mml/v4/sets.rb +57 -0
data/lib/mml/v4/statistics.rb +33 -0
data/lib/mml/v4/tendsto.rb +9 -0
data/lib/mml/v4/vector_calculus.rb +21 -0
data/lib/mml/v4.rb +421 -44
data/lib/mml/version.rb +1 -1
data/lib/mml/versioned_parser.rb +1 -1
data/lib/mml.rb +3 -1
data/reference-docs/mathml-source/pubtext/mathmlspec.dtd +150 -0
data/reference-docs/mathml-source/pubtext/xmlspec.dtd +2649 -0
data/reference-docs/mathml-source/readme.txt +40 -0
data/reference-docs/mathml-source/run +296 -0
data/reference-docs/mathml-source/style/html/html2xhtml.xsl +216 -0
data/reference-docs/mathml-source/style/html/images.xsl +98 -0
data/reference-docs/mathml-source/style/html/mml6.xsl +1156 -0
data/reference-docs/mathml-source/style/html/mmldiff.xsl +566 -0
data/reference-docs/mathml-source/style/html/mmlspec.xsl +2531 -0
data/reference-docs/mathml-source/style/html/slices-common.xsl +312 -0
data/reference-docs/mathml-source/style/html/slices.xsl +48 -0
data/reference-docs/mathml-source/style/html/xmlspec.xsl +2542 -0
data/reference-docs/mathml-source/style/pdf/mathmlspec.xsl +2510 -0
data/reference-docs/mathml-source/xml/changes.xml +773 -0
data/reference-docs/mathml-source/xml/character-set.xml +1011 -0
data/reference-docs/mathml-source/xml/content-element-def.xml +6143 -0
data/reference-docs/mathml-source/xml/content-markup.xml +8178 -0
data/reference-docs/mathml-source/xml/contributors.xml +425 -0
data/reference-docs/mathml-source/xml/dom-bindings.xml +20 -0
data/reference-docs/mathml-source/xml/dom-intro.xml +114 -0
data/reference-docs/mathml-source/xml/fundamentals.xml +1646 -0
data/reference-docs/mathml-source/xml/glossary.xml +519 -0
data/reference-docs/mathml-source/xml/interface.xml +1096 -0
data/reference-docs/mathml-source/xml/introduction.xml +724 -0
data/reference-docs/mathml-source/xml/mathml-css-sample.xml +304 -0
data/reference-docs/mathml-source/xml/mathml-dom.xml +3813 -0
data/reference-docs/mathml-source/xml/mathml-spec.xml +356 -0
data/reference-docs/mathml-source/xml/mixing.xml +982 -0
data/reference-docs/mathml-source/xml/operator-dict.xml +551 -0
data/reference-docs/mathml-source/xml/parsing.xml +2565 -0
data/reference-docs/mathml-source/xml/presentation-markup.xml +6834 -0
data/reference-docs/mathml-source/xml/references.xml +323 -0
data/reference-docs/mathml-source/xml/validation-grammar.xml +877 -0
data/schemas/README.adoc +17 -0
data/schemas/mathml2/common/common-attribs.xsd +41 -0
data/schemas/mathml2/common/math.xsd +126 -0
data/schemas/mathml2/common/xlink-href.xsd +20 -0
data/schemas/mathml2/content/CVS/Entries +16 -0
data/schemas/mathml2/content/CVS/Repository +1 -0
data/schemas/mathml2/content/CVS/Root +1 -0
data/schemas/mathml2/content/arith.xsd +90 -0
data/schemas/mathml2/content/calculus.xsd +146 -0
data/schemas/mathml2/content/common-attrib.xsd +30 -0
data/schemas/mathml2/content/constants.xsd +83 -0
data/schemas/mathml2/content/constructs.xsd +260 -0
data/schemas/mathml2/content/elementary-functions.xsd +117 -0
data/schemas/mathml2/content/functions.xsd +73 -0
data/schemas/mathml2/content/linear-algebra.xsd +173 -0
data/schemas/mathml2/content/logic.xsd +53 -0
data/schemas/mathml2/content/relations.xsd +55 -0
data/schemas/mathml2/content/semantics.xsd +85 -0
data/schemas/mathml2/content/sets.xsd +236 -0
data/schemas/mathml2/content/statistics.xsd +136 -0
data/schemas/mathml2/content/tokens.xsd +120 -0
data/schemas/mathml2/content/tokens.xsd.~1.3.~ +119 -0
data/schemas/mathml2/content/vector-calculus.xsd +88 -0
data/schemas/mathml2/mathml2.xsd +59 -0
data/schemas/mathml2/presentation/action.xsd +44 -0
data/schemas/mathml2/presentation/characters.xsd +37 -0
data/schemas/mathml2/presentation/common-attribs.xsd +113 -0
data/schemas/mathml2/presentation/common-types.xsd +103 -0
data/schemas/mathml2/presentation/error.xsd +40 -0
data/schemas/mathml2/presentation/layout.xsd +195 -0
data/schemas/mathml2/presentation/scripts.xsd +186 -0
data/schemas/mathml2/presentation/space.xsd +52 -0
data/schemas/mathml2/presentation/style.xsd +69 -0
data/schemas/mathml2/presentation/table.xsd +216 -0
data/schemas/mathml2/presentation/tokens.xsd +124 -0
data/schemas/mathml3/mathml3-common.xsd +99 -0
data/schemas/mathml3/mathml3-content.xsd +684 -0
data/schemas/mathml3/mathml3-presentation.xsd +2151 -0
data/schemas/mathml3/mathml3-strict-content.xsd +186 -0
data/schemas/mathml3/mathml3.xsd +9 -0
data/schemas/mathml4/mathml4-content.rnc +382 -0
data/schemas/mathml4/mathml4-core.rnc +361 -0
data/schemas/mathml4/mathml4-presentation.rnc +358 -0
data/schemas/mathml4/mathml4-strict-content.rnc +86 -0
data/schemas/mathml4/mathml4.rnc +21 -0
data/schemas/mathml4/mathml4.rnc.1 +21 -0
data/schemas/mathml4/mathml4.rng +37 -0
metadata +249 -2

data/reference-docs/mathml-source/xml/interface.xml ADDED Viewed

@@ -0,0 +1,1096 @@
+<div1 id="interf" role="chapter7"><head>The MathML Interface</head>
+<!-- $Id: interface.xml,v 1.70 2003/08/14 15:13:01 rminer Exp $ -->
+<p>To be effective, MathML must work well with a wide variety of
+renderers, processors, translators and editors. This chapter addresses
+some of the interface issues involved in generating and rendering
+MathML. Since MathML exists primarily to encode mathematics in Web
+documents, perhaps the most important interface issues are related to
+embedding MathML in <bibref ref="HTML4" /> and
+<bibref ref="XHTML"/>.</p>
+<p>There are three kinds of interface issues that arise in embedding
+MathML in other XML documents. First, MathML must be semantically
+integrated. MathML markup must be recognized as valid embedded XML
+content, and not as an error.  This is primarily a question of
+managing namespaces in XML <bibref ref="Namespaces"/>.</p>
+<p>Second, in the case of HTML/XHTML, MathML rendering must be
+integrated into browser software.  Some browsers already implement
+MathML rendering natively, and one can expect more browsers will do so
+in the future.  At the same time, other browsers have developed
+infrastructure to facilitate the rendering of MathML and other
+embedded XML content by third-party software.  Using these browser
+specific mechanisms generally requires some additional interface
+markup of some sort to activate them.</p>
+<p>Third, other tools for generating and processing MathML must be
+able to intercommunicate.  A number of MathML tools have been or are
+being developed, including editors, translators, computer algebra
+systems, and other scientific software.  However, since MathML
+expressions tend to be lengthy, and prone to error when entered by
+hand, special emphasis must be given to insuring that MathML can be
+easily generated by user-friendly conversion and authoring tools, and
+that these tools work together in a dependable, platform and vendor
+independent way.</p>
+<p>The W3C Math Working Group is committed to providing support to software
+vendors developing any kind of MathML tool. The Working Group monitors
+the public mailing list
+<loc href="mailto:www-math@w3.org">www-math@w3.org</loc>,
+and will attempt to answer questions about the MathML specification. The
+Working Group works with MathML developer
+and user groups. For current information about MathML tools, applications
+and user support activities, consult the
+<loc href="http://www.w3.org/Math/">home page of the W3C Math Working
+Group</loc>.</p>
+<div2 id="interf_embed"><head>Embedding MathML in other Documents</head>
+<p>While MathML can be used in isolation as a language for exchanging
+mathematical expressions between MathML-aware applications, the
+primary anticipated use of MathML is to encode mathematical expression
+within larger documents.  MathML is ideal for embedding math
+expressions in other applications of XML.</p>
+<p>In particular, the focus here is on the mechanics of embedding
+MathML in <bibref ref="XHTML"/>. XHTML is a W3C Recommendation
+formulating a family of current and future XML-based document types
+and modules that reproduce, subset, and extend HTML.  While <bibref
+ref="HTML4"/> is the dominant language of the Web at the time of
+this writing, one may anticipate a shift from HTML to XHTML.
+Indeed, XHTML can already be made to render properly in most HTML user
+agents.</p>
+<p>Since MathML and XHTML share a common XML framework, namespaces
+provide a standard mechanism for embedding MathML in XHTML.  While
+some popular user agents also support inclusion of MathML directly in
+HTML as "XML data islands," this is a transitional strategy.
+Consult user agent documentation for specific information on
+its support for embedding XML in HTML.</p>
+<div3 id="interf_namespace"><head>MathML and Namespaces</head>
+<p>Embedding MathML in XML-based documents in general, and XHTML in
+particular, is a matter of managing namespaces.  See the W3C
+Recommendation "Namespaces in XML" <bibref
+ref="Namespaces"/> for full details.</p>
+<p>An XML namespace is a collection of names identified by a URI.  The
+URI for the MathML namespace is:</p>
+<eg>
+http://www.w3.org/1998/Math/MathML
+</eg>
+<p>Using namespaces, embedding a MathML expression in a larger XML
+document is merely a matter of identifying the MathML markup as
+residing in the MathML namespace.  This can be accomplished by either
+explicitly identifying each MathML element name by attaching a
+namespace prefix, or by declaring a default namespace on an enclosing
+element.</p>
+<p>To declare a namespace, one uses an <att>xmlns</att>
+attribute, or an attribute
+with an <att>xmlns</att> prefix.  When the <att>xmlns</att> attribute is used alone, it sets
+the default namespace for the element on which it
+appears, and for any children elements.</p>
+<p>Example:</p>
+<eg><![CDATA[
+<math xmlns="http://www.w3.org/1998/Math/MathML">
+<mrow>...</mrow>
+</math>
+]]></eg>
+<p>When the <att>xmlns</att> 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.</p>
+<p>Example:</p>
+<eg><![CDATA[
+<body xmlns:m="http://www.w3.org/1998/Math/MathML">
+...
+<m:math><m:mrow>...</m:mrow></m:math>
+...
+</body>
+]]></eg>
+<p>These two methods of namespace declaration can be used together.
+For example, by using both an explicit document-wide namespace prefix,
+and default namespace declarations on individual mathematical
+elements, it is possible to localize namespace related markup to the
+top-level <el>math</el> element.  <phrase diff="del">This is also
+important for implementation with some user agents, since attaching
+rendering behaviors to an element currently requires an explicit
+namespace prefix in these browsers.  At the same time, a number of
+MathML authoring tools are not yet namespace-aware, and thus the
+ability to use markup without prefixes is also desirable in the short
+term.</phrase></p>
+<p>Example:</p>
+<eg><![CDATA[
+<body xmlns:m="http://www.w3.org/1998/Math/MathML">
+...
+<m:math xmlns="http://www.w3.org/1998/Math/MathML">
+<mrow>...<mrow>
+</m:math>
+...
+</body>
+]]></eg>
+<div4 id="interf_validation"><head>Document Validation Issues</head>
+<p>The use of namespace prefixes creates an issue for DTD validation
+of documents embedding MathML.  DTD validation requires knowing the
+literal (possibly prefixed) element names used in the document.
+However, the Namespaces in XML Recommendation <bibref
+ref="Namespaces"/> allows the prefix to be changed at arbitrary points
+in the document, since namespace prefixes may be declared on any
+element.</p>
+<p>The 'historical' method of bridging this gap was to write a DTD
+with a fixed prefix, or in the case of XHTML and MathML, with no
+prefix, and mandate that the specified form must be used throughout
+the document.  However, this is somewhat restricting for a modular DTD
+that is intended for use in conjunction with another DTD, which is
+exactly the situation with MathML in XHTML.  In essence, the MathML
+DTD would have to allocate a prefix for itself and hope no
+other module uses the same prefix to avoid name clashes, thus losing
+one of the main benefits of XML namespaces.</p>
+<p>One strategy for addressing this problem is to make every element
+name in the DTD be accessed by an entity reference. This means that by
+declaring a couple of entities to specify the prefix before the DTD is
+loaded, the prefix can be chosen by a document author, and compound
+DTDs that include several modules can, without changing the module
+DTDs, specify unique prefixes for each module to avoid clashes.  The
+MathML DTD has been designed in this fashion. See <specref
+ref="parsing_dtd" /> and <bibref ref="Modularization"/> for
+details.</p>
+<p>An extra issue arises in the case where explicit prefixes are used
+on the top-level <el>math</el> element, but a default
+namespace is used for other MathML elements.  In this case, one wants
+the MathML module to be included into XHTML with the prefix set to
+empty.  However, the 'driver' DTD file that sets up the inclusion of
+the MathML module would then need to define a new element called
+m:math.  This would allow the top-level <el>math</el>
+element to use an explicit prefix, for attaching rendering behaviors
+in current browsers, while the contents would not need an explicit
+prefix, for ease of interoperability between authoring tools, etc.</p>
+</div4>
+<div4 id="interf_compatibility"><head>Compatibility Suggestions</head>
+<p>While the use of namespaces to embed MathML in other XML
+applications is completely described by the relevant W3C
+Recommendations, a certain degree of pragmatism is still called for at
+present.  Support for XML, namespaces and rendering behaviors in
+popular user agents is not always fully in alignment with W3C
+Recommendations.  In some cases, the software predates the relevant
+standards, and in other cases, the relevant standards are not yet
+complete.</p>
+<p>During the transitional period, in which some software may not be
+fully namespace-aware, a few conventional practices will ease
+compatibility problems:
+<olist>
+<item><p>When using namespace prefixes with MathML markup, use m: as a
+conventional prefix for the MathML namespace.  Using an explicit
+prefix is probably safer for compatibility in current user agents.
+</p></item>
+<item><p>When using namespace prefixes, pick one and use it
+consistently within a document.
+</p></item>
+<item><p>Explicitly declare the MathML namespace on all
+<el>math</el> elements.
+</p></item> </olist></p>
+<p>Examples.</p>
+<eg><![CDATA[
+<body>
+...
+<m:math xmlns:m="http://www.w3.org/1998/Math/MathML">
+<m:mrow>...<m:mrow>
+</m:math>
+...
+</body>
+]]></eg>
+<p>Or</p>
+<eg><![CDATA[
+<body>
+...
+<math xmlns="http://www.w3.org/1998/Math/MathML">
+<mrow>...<mrow>
+</math>
+...
+</body>
+]]></eg>
+<p>Note that these suggestions alone may not be sufficient for
+creating functional Web pages containing MathML markup.  It will
+generally be the case that some additional document-wide markup will
+be required.  Additional work may also be required to make all MathML
+instances in a document compatible with document-wide declarations.
+This is particularly true when documents are created by cutting and
+pasting MathML expressions, since current tools will probably not
+be able to query global namespace information.</p>
+<p>Consult the <loc href="http://www.w3.org/Math/">W3C Math Working
+Group</loc> home page for compatibility and implementation suggestions
+for current browsers and other MathML-aware tools.</p>
+</div4>
+</div3>
+<div3 id="interf_toplevel"><head>The Top-Level
+<el>math</el> Element</head>
+<p>MathML specifies a single top-level or root <el>math</el> element, which encapsulates each instance of
+MathML markup within a document.  All other MathML content must be
+contained in a <el>math</el> element; equivalently,
+every valid, complete MathML expression must be contained in <el role="starttag">math</el> tags. The <el>math</el>
+element must always be the outermost element in a MathML expression;
+it is an error for one <el>math</el> element to contain
+another.</p>
+<p>Applications that return sub-expressions of other MathML
+expressions, for example, as the result of a cut-and-paste operation,
+should always wrap them in <el role="starttag">math</el>
+tags. Ideally, the presence of enclosing <el role="starttag">math</el>
+tags should be a very good heuristic test for MathML
+material. Similarly, applications which insert MathML expressions in
+other MathML expressions must take care to remove the <el role="starttag">math</el> tags from the inner expressions.</p>
+<p>The <el>math</el> element can contain an arbitrary number
+of children schemata. The children schemata render by default as if they
+were contained in an <el>mrow</el> element.</p>
+<p>The attributes of the <el>math</el> element are:
+<glist>
+<gitem><label>class, id, style</label>
+<def><p>Provided for use with stylesheets.</p></def>
+</gitem>
+<gitem><label>xref</label>
+<def><p>Provided along with <att>id</att> for use
+with XSL processing (See <specref ref="mixing_tools" />)</p></def>
+</gitem>
+<gitem><label>macros</label>
+<def><p>This attribute provides a way of pointing to
+external macro definition files. Macros are not part of the MathML
+specification, and much of the functionality provided by macros in MathML can be
+accommodated by XSL transformations <bibref ref="XSLT"/>.  However, the <att>macros</att> attribute is provided to make possible future
+development of more streamlined, MathML-specific macro mechanisms. The
+value of this attribute is a sequence of URLs or URIs, separated by
+whitespace</p></def>
+</gitem>
+<gitem>
+<label>mode</label>
+<def><p>The <att>mode</att> attribute specifies whether
+the enclosed MathML expression should be rendered in a display style
+or an in-line style. Allowed values are
+<attval>display</attval> and
+<attval>inline</attval> (default).
+This attribute is <intref ref="interf_deprec">deprecated</intref> in
+favor of the new <att>display</att> attribute, or the
+<loc href="http://www.w3.org/TR/CSS2/visuren.html#propdef-display">CSS2
+'display' property</loc> with the analogous <kw>block</kw> and
+<kw>inline</kw> values.</p></def>
+</gitem>
+<gitem>
+<label>display</label>
+<def><p>The <att>display</att> attribute replaces the
+deprecated <att>mode</att> <phrase diff="chg">attribute</phrase>.
+It specifies whether
+the enclosed MathML expression should be rendered in a display style
+or an in-line style. Allowed values are
+<attval>block</attval> and
+<attval>inline</attval> (default).
+</p></def>
+</gitem>
+</glist>
+</p>
+<p>The attributes of the <el>math</el> element affect
+the entire enclosed expression. They are, in a sense, <quote>inward
+looking</quote>. However, to render MathML properly in a browser, and
+to integrate it properly into an XHTML document, a second collection
+of <quote>outward looking</quote> attributes are also useful.</p>
+<p>While general mechanisms for attaching rendering behaviors to
+elements in XML documents are under development, wide variations in
+strategy and level of implementation remain between various existing
+user agents.  Consequently, the remainder of this section describes
+attributes and functionality that are desirable for integrating
+third-party rendering modules with user agents:
+<glist>
+<gitem><label>overflow</label> <def><p>In cases where size negotiation
+is not possible or fails (for example in the case of an extremely long
+equation), this attribute is provided to suggest an alternative
+processing method to the renderer.  Allowed values are <glist>
+<gitem><label>scroll</label> <def><p>The window provides a viewport
+into the larger complete display of the mathematical
+expression. Horizontal or vertical scrollbars are added to the window
+as necessary to allow the viewport to be moved to a different
+position.</p></def> </gitem>
+<gitem><label>elide</label>
+<def><p>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 <quote>+ ... +</quote> between
+them. Advanced renderers may provide a facility to zoom in on elided
+areas.</p></def>
+</gitem>
+<gitem><label>truncate</label>
+<def><p>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.</p></def>
+</gitem>
+<gitem><label>scale</label>
+<def><p>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.</p></def>
+</gitem>
+</glist>
+</p>
+</def>
+</gitem>
+<gitem><label>altimg</label>
+<def><p>This attribute provides a graceful fall-back for browsers that do
+not support embedded elements. The value of the
+attribute is an URL.</p></def>
+</gitem>
+<gitem><label>alttext</label>
+<def><p>This attribute provides a graceful fall-back for browsers that do
+not support embedded elements or images.
+The value of the attribute is a text string.</p></def>
+</gitem>
+</glist>
+</p>
+</div3>
+<div3><head>Invoking MathML Processors</head>
+<p>In browsers where MathML is not natively supported, it is anticipated
+that MathML rendering will be carried out via embedded objects such as
+plug-ins, applets, or helper applications.  The direction which has
+begun emerging for invoking third-party rendering and processing
+software is elucidated in the W3C Working Draft "Behavioral
+Extensions to CSS" <bibref ref="Behaviors" />.</p>
+<p>Behavioral extensions use the linking mechanism of CSS to attach
+executable components to elements.  Typically, the executable
+components involve script code which manipulate the DOM to instantiate
+other MathML processing components.  Using experimental
+implementations of behavior extensions in current user agents, it is
+possible to attach processing components to <el>math</el> elements which then carry out the rendering
+of MathML markup in an XHTML page.</p>
+<p>Work on on Behavior Extensions to CSS is ongoing at W3C, and
+existing implementations must be regarded as non-standard at this time.
+However, it offers a very promising direction for powerful and
+flexible invocation of third-party MathML processors.</p>
+<p>MIME types <bibref ref="RFC2045" />, <bibref ref="RFC2046" /> offer
+an alternative strategy that can also be used in current user agents
+to invoke a MathML renderer.  This is primarily useful when
+referencing separate files containing MathML markup from an <el
+namespace="xhtml">embed</el> or <el namespace="xhtml">object</el> element.
+<bibref ref="RFC3023" /> assigns MathML the MIME type
+<code>application/mathml+xml</code>.  The W3C Math Working Group
+recommends the standard file extension <code>.mml</code> used for
+browser registry.</p>
+<p>In MathML 1.0, <code>text/mathml</code> was given as the suggested
+MIME type.  This has been superceded by RFC3023.</p>
+<p>Although rendering MathML expressions typically occurs in place in
+a Web browser, other MathML processing functions take place more
+naturally in other applications. Particularly common tasks include
+opening a MathML expression in an equation editor or computer algebra
+system.</p>
+<p>At present, there is no standard way of selecting between various
+applications which might be used to render or process embedded MathML.
+As work progresses on coordination between browsers and embedded
+elements and the Document Object Model <bibref ref="DOM" />, providing
+this kind of functionality should be a priority. Both authors and
+readers should be able to indicate a preference about what MathML
+application to use in a given context. For example, one might imagine
+that some mouse gesture over a MathML expression causes a browser to
+present the reader with a pop-up menu, showing the various kinds of
+MathML processing available on the system, and the MathML processors
+recommended by the author.</p>
+<p>Since MathML is most often generated by authoring tools, it is
+particularly important that opening a MathML expression in an editor should
+be easy to do and to implement. In many cases, it will be desirable for an
+authoring tool to record some information about its internal state along
+with a MathML expression, so that an author can pick up editing where he or
+she left off.  The MathML specification does not explicitly contain
+provisions for recording information about the authoring tool. In some
+circumstances, it may be possible to include authoring tool information
+that applies to an entire document in the form of meta-data; interested
+readers are encouraged to consult the <loc
+href="http://www.w3.org/Metadata/">W3C Metadata Activity</loc> for current
+information about metadata and resource definition. For encoding authoring
+tool state information that applies to a particular MathML instance,
+readers are referred to the possible use of the <el>semantics</el> element for this purpose <specref
+ref="contm_semantics"/>.</p>
+<p>In the short term, regardless of the methodology, implementors of
+embedded MathML processing applications are encouraged to try to allow for
+the following kinds of functionality:
+<ulist>
+<item><p>An author wishing to reach an audience as wide as possible
+might want MathML to be rendered by any available processor.</p>
+</item>
+<item><p>An author targeting a specific audience might want to indicate that
+a particular MathML processor be used.</p>
+</item>
+<item><p>A reader might wish to specify which of several available
+processors installed locally should be used.</p>
+</item>
+</ulist>
+</p>
+</div3>
+<div3 id="interf_link"><head>Mixing and Linking MathML and HTML</head>
+<p>In order to fully integrate MathML into XHTML, it should be possible
+not only to embed MathML in XHTML, but also to embed XHTML in MathML.
+However, the problem of supporting XHTML in MathML presents many
+difficulties.  Therefore, at present, the MathML specification does not
+permit any XHTML elements within a MathML expression, although this
+may be subject to change in a future revision of MathML.</p>
+<p>In most cases, XHTML elements (headings, paragraphs, lists, etc.)
+either do not apply in mathematical contexts, or MathML already
+provides equivalent or better functionality specifically tailored to
+mathematical content (tables, mathematics style changes,
+etc.). However, there are two notable exceptions, the XHTML anchor and
+image elements.  For this functionality, MathML relies on the general
+XML linking and graphics mechanisms being developed by other W3C
+Activities. </p>
+<div4><head>Linking</head>
+<p>MathML has no element that corresponds to the XHTML anchor element
+<var>a</var>. In XHTML, anchors are used both to make links, and to
+provide locations to which a link can be made. MathML, as an XML
+application, defines links by the use of the mechanism described in
+the W3C <phrase diff="del">Candidate</phrase> Recommendation "XML
+Linking Language" <bibref ref="XLink"/>.<phrase diff="del">The reader
+is cautioned that at the time of this writing, XLink is not yet a
+Recommendation, and is therefore subject to future revision. Since the
+MathML linking mechanism is defined in terms of the XML linking
+specification, the same proviso holds for it as well.</phrase></p>
+<p>A MathML element is designated as a link by the presence of the
+attribute <att>xlink:href</att>.  To use the attribute <att>xlink:href</att>, it is also necessary to declare the
+appropriate namespace. Thus, a typical MathML link might look like:
+<eg><![CDATA[
+<mrow xmlns:xlink="http://www.w3.org/1999/xlink"
+      xlink:href="sample.xml">
+  ...
+</mrow>
+]]></eg>
+</p>
+<p>MathML designates that almost all elements can be used as XML linking
+elements. The only elements that cannot serve as linking elements are those
+such as the <el>sep</el> element, which exist primarily to
+disambiguate other MathML constructs and in general do not correspond to
+any part of a typical visual rendering. The full list of exceptional
+elements that cannot be used as linking elements is given in the table
+below.
+<table width="75%">
+<thead>
+<tr><td colspan="3">MathML elements that cannot be linking elements.</td></tr>
+</thead>
+<tbody>
+<tr>
+<td><el>mprescripts</el></td>
+<td><el>none</el></td>
+<td><el>sep</el></td>
+</tr>
+<tr>
+<td><el>malignmark</el></td>
+<td><el>maligngroup</el></td>
+<td></td>
+</tr>
+</tbody>
+</table>
+</p>
+<p>Note that the XML Linking <bibref
+ref="XLink"/> and XML Pointer Language <bibref
+ref="XPointer"/> specifications also define how to link
+<emph>into</emph> a MathML expressions.  Be aware, however, that such
+links may or may not be properly interpreted in current software.</p>
+</div4>
+<div4><head>Images</head>
+<p>The <el namespace="xhtml">img</el> element has no MathML
+equivalent. The decision to omit a general mechanism for image
+inclusion from MathML was based on several factors.  However, the main
+reason for not providing an image facility is that MathML takes great
+pains to make the notational structure and mathematical content it
+encodes easily available to processors, whereas information contained
+in images is only available to a human reader looking at a visual
+representation. Thus, for example, in the MathML paradigm, it would be
+preferable to introduce new glyphs via the <el>mglyph</el> element which at a minimum identifies them
+as glyphs, rather than simply including them as images.</p>
+</div4>
+</div3>
+<div3 id="interf_graphics" diff="add"><head>MathML and Graphical Markup</head>
+<p>Apart from the introduction of new glyphs, many of the situations
+where one might be inclined to use an image amount to displaying
+labeled diagrams. For example, knot diagrams, Venn diagrams, Dynkin
+diagrams, Feynman diagrams and commutative diagrams all fall into this
+category. As such, their content would be better encoded via some
+combination of structured graphics and MathML markup.  However, at the
+time of this writing, it is beyond the scope of the W3C Math Activity
+to define a markup language to encode such a general concept as
+<quote>labeled diagrams.</quote> (See <loc
+href="http://www.w3.org/Math/">http://www.w3.org/Math</loc> for
+current W3C activity in mathematics and <loc
+href="http://www.w3.org/Graphics/">http://www.w3.org/Graphics</loc>
+for the W3C graphics activity.)</p>
+<p>One mechanism for embedding additional graphical content is via the
+<el>semantics</el> element, as in the following example:
+<eg><![CDATA[<semantics>
+  <apply>
+    <intersect/>
+    <ci>A</ci>
+    <ci>B</ci>
+  </apply>
+  <annotation-xml encoding="SVG1.1">
+    <svg xmlns="http://www.w3.org/2000/svg"  viewBox="0 0 290 180">
+      <clipPath id="a">
+      <circle cy="90" cx="100" r="60"/>
+      </clipPath>
+      <circle fill="#AAAAAA" cy="90" cx="190"
+              r="60" style="clip-path:url(#a)"/>
+      <circle stroke="black" fill="none" cy="90" cx="100" r="60"/>
+      <circle stroke="black" fill="none" cy="90" cx="190" r="60"/>
+    </svg>
+  </annotation-xml>
+  <annotation-xml encoding="application/xhtml+xml">
+    <img xmlns="http://www.w3.org/1999/xhtml" src="intersect.gif" alt="A intersect B"/>
+  </annotation-xml>
+</semantics>]]></eg>
+   Here, the <el>annotation-xml</el> elements are used to indicate alternative
+   representations of the Content MathML depiction of the
+   intersection of two sets.
+   The first one is in the <quote>Scalable Vector
+     Graphics</quote> format <bibref ref="SVG1.1"/>
+   (see <bibref ref="XHTML-MathML-SVG"/> for the definition of an XHTML profile integrating MathML and SVG), the second one uses the
+   XHTML <el namespace="xhtml">img</el> element embedded as an XHTML fragment.
+In this situation, a MathML processor can use any of these
+   representations for display,  perhaps producing a graphical format
+   such as the image below.</p>
+  <graphic role="display" source="image/intersect.gif" alt="\includegraphics{intersect}"/>
+  <p>Note that the semantics representation of this example is given
+  in the Content MathML markup, as the first child of the
+  <el>semantics</el> element.  In this regard, it is the
+  representation most analogous to the <att>alt</att> attribute of the
+  <el namespace="xhtml">img</el> element in XHTML, and would likely be
+  the best choice for non-visual rendering.</p>
+</div3>
+<div3 id="interf_style"><head>Using CSS with MathML</head>
+<p>When MathML is rendered in an environment
+that supports CSS, controlling mathematics style properties with a CSS
+stylesheet is obviously desirable.
+MathML 2.0 has significantly redesigned the way presentation element
+style properties are organized to facilitate better interaction
+between MathML renderers and CSS style mechanisms.  It introduces four
+new <emph>mathematics style</emph> attributes with logical values.  Roughly
+speaking, these attributes can be viewed as the proper selectors for
+CSS rules that affect MathML.</p>
+<p>Controlling mathematics styling is not as simple as it might first appear
+because mathematics styling and text styling are quite different in
+character.  In text, meaning is primarily carried by the relative
+positioning of characters next to one another to form words.  Thus,
+although the font used to render text may impart nuances to the
+meaning, transforming the typographic properties of the individual
+characters leaves the meaning of text basically intact.  By contrast,
+in mathematical expressions, individual characters in specific
+typefaces tend to function as atomic symbols.  Thus, in the same
+equation, a bold italic 'x' and a normal italic 'x' are almost always
+intended to be two distinct symbols that mean different things.  In
+traditional usage, there are eight basic typographical categories
+of symbols.  These categories are described by mathematics style
+attributes, primarily the <att>mathvariant</att>
+attribute.</p>
+<p>Text and mathematics layout also obviously differ in that
+mathematics uses 2-dimensional layout.  As a result, many of the style
+parameters that affect mathematics layout have no textual analogs.
+Even in cases where there are analogous properties, the sensible
+values for these properties may not correspond.  For example,
+traditional mathematical typography usually uses italic fonts for
+single character identifiers, and upright fonts for multicharacter
+identifier.  In text, italicization does not usually depend on the
+number of letters in a word.  Thus although a font-slant property
+makes sense for both mathematics and text, the natural default values
+are quite different.</p>
+<p>Because of the difference between text and mathematics styling, only some
+aspects of MathML layout are good candidates for CSS control.  MathML
+2.0 captures the most important properties with the new mathematics style
+attributes, and users should try to use them whenever possible over
+more direct, but less robust, approaches.  A sample CSS stylesheet
+illustrating the use of the mathematical
+style attributes is available in <specref ref="stylesheet"/></p>
+<p>Generally speaking, the model for CSS interaction with the math
+style attributes runs as follows.  A CSS style sheet might provide a style
+rule such as:</p>
+<eg><![CDATA[
+math *.[mathsize="small"] {
+  font-size: 80%
+}
+]]></eg>
+<p>This rule sets the CSS font-size properties for all children of the
+<el>math</el> element that have the <att>mathsize</att> attribute set to small.  A MathML renderer
+would then query the style engine for the CSS environment, and use the
+values returned as input to its own layout algorithms.  MathML does
+not specify the mechanism by which style information is inherited from
+the environment.  However, some suggested rendering rules for the
+interaction between properties of the ambient style environment and
+MathML-specific rendering rules are discussed in <specref
+ref="presm_commatt"/>, and more generally throughout <specref
+ref="presm"/>.</p>
+<p>It should be stressed, however, that some caution is required in
+writing CSS stylesheets for MathML.  Because changing typographic
+properties of mathematics symbols can change the meaning of an equation,
+stylesheet should be written in a way such that changes to document-wide
+typographic styles do not affect embedded MathML expressions.  By
+using the MathML 2.0 mathematics style attributes as selectors for CSS rules,
+this danger is minimized.</p>
+<p>Another pitfall to be avoided is using CSS to provide
+typographic style information necessary to the proper understanding of
+an expression.  Expressions dependent on CSS for meaning will not be
+portable to non-CSS environments such as computer algebra systems.  By
+using the logical values of the new MathML 2.0 mathematics style attributes
+as selectors for CSS rules, it can be assured that style information
+necessary to the sense of an expression is encoded directly in the
+MathML.</p>
+<p>MathML 2.0 does not specify how a user agent should process style
+information, because there are many non-CSS MathML environments, and
+because different users agents and renderers have widely varying
+degrees of access to CSS information.  In general, however, developers
+are urged to provide as much CSS support for MathML as possible.</p>
+</div3>
+</div2>
+<div2 id="interf_genproc"><head>Conformance</head>
+<p>Information is increasingly 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. Thus, although MathML
+can be written by hand and read by humans, 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 <phrase diff="chg">
+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.</phrase>  What it
+means to support MathML varies widely between applications.  For
+example, the issues that arise with a <phrase diff="del">MathML-compliant</phrase> validating
+parser are very different from those for a <phrase diff="del">MathML-compliant</phrase> equation
+editor.</p>
+<p>In this section, guidelines are given for describing different types
+of MathML support, and for quantifying 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 and interoperability
+between MathML applications by accurately characterizing their
+capabilities in quantifiable terms.</p>
+<p>The W3C Math Working Group maintains <loc
+href="http://www.w3.org/Math/iandi/compliance" diff="chg">MathML 2.0 Conformance
+Guidelines</loc>.  Consult this document for future updates on
+conformance activities and resources.
+</p>
+<div3><head diff="chg">MathML Conformance</head>
+<p>A valid MathML expression is an XML construct determined by the MathML
+DTD together with the additional requirements given in this specification.</p>
+<p>Define a <quote>MathML processor</quote> to mean any application that
+can accept, produce, or <quote>roundtrip</quote> a valid MathML
+expression. An example of an application that might round-trip a MathML
+expression might be an editor that writes a new file even though no
+modifications are made.</p>
+<p>Three forms of MathML <phrase diff="chg">conformance</phrase> are specified:
+<olist>
+<item><p>A MathML-input-<phrase diff="chg">conformant</phrase> processor must accept all valid MathML
+expressions, and faithfully translate all MathML expressions into
+application-specific form allowing native application operations to be
+performed.</p>
+</item>
+<item><p>A MathML-output-<phrase diff="chg">conformant</phrase> processor must generate valid MathML,
+faithfully representing all <phrase>application-specific</phrase> data.</p>
+</item>
+<item><p>A MathML-roundtrip-<phrase diff="chg">conformant</phrase> processor must preserve MathML
+equivalence. Two MathML expressions are <quote>equivalent</quote> if and
+only if both expressions have the same interpretation (as stated by the
+MathML DTD and  specification) under any circumstances, by any MathML
+processor. Equivalence on an element-by-element basis is discussed
+elsewhere in this document.</p>
+</item>
+</olist>
+</p>
+<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 suggested
+rendering rules throughout <specref ref="presm"/>.  However, in general,
+developers are given wide latitude in interpreting what kind of MathML
+implementation is meaningful for their own particular application.</p>
+<p>To clarify the difference between <phrase diff="chg">conformance</phrase> and interpretation of
+what is meaningful, consider some examples:
+<olist>
+<item><p>In order to be MathML-input-<phrase diff="chg">conformant</phrase>, a validating parser needs
+only to accept expressions, and return <quote>true</quote> for
+expressions that are valid MathML. In particular, it need not render or
+interpret the MathML expressions at all.</p>
+</item>
+<item><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-<phrase diff="chg">conformant</phrase>.</p>
+</item>
+<item><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-<phrase diff="chg">conformant</phrase>.</p> </item> </olist> </p>
+<div4 id="interf_testsuite"><head>MathML Test Suite and Validator</head>
+<p>As the previous examples show, to be useful, the concept of MathML
+<phrase diff="chg">conformance</phrase> 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 <phrase diff="chg">conformance</phrase>.  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 <loc href="http://www.w3.org/Math/testsuite/">test
+suite</loc>.</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<phrase diff="chg">-conformant</phrase> 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-<phrase diff="chg">conformant</phrase> processors, there is also a <loc
+href="http://www.w3.org/Math/validator/">MathML validator</loc>
+accessible over the Web.  Developers of MathML-output-<phrase diff="chg">conformant</phrase>
+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>
+</div4>
+<div4 id="interf_deprec"><head>Deprecated MathML 1.x Features</head>
+<p>MathML 2.0 contains a number of MathML 1.x features 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 MathML 2.0 <phrase diff="chg">conformance</phrase>.</p>
+<olist>
+<item><p>In order to be MathML-output-<phrase diff="chg">conformant</phrase>, authoring tools may not
+generate MathML markup containing deprecated features.</p></item>
+<item><p>In order to be MathML-input-<phrase diff="chg">conformant</phrase>, rendering/reading
+tools must support deprecated features if they are to be
+<phrase diff="chg">in conformance with MathML 1.x</phrase>.   They do not have to support deprecated
+features to be considered <phrase diff="chg">in conformance with MathML 2.0</phrase>.  However, all tools
+are encouraged to support the old forms as much as
+possible.</p></item>
+<item><p>In order to be MathML-roundtrip-<phrase diff="chg">conformant</phrase>, a processor need
+only preserve MathML equivalence on expressions containing no
+deprecated features.</p></item>
+</olist>
+</div4>
+<div4 diff="add" id="interf_extension"><head>MathML 2.0 Extension Mechanisms and Conformance</head>
+<p>MathML 2.0 defines three extension mechanisms:  The <el>mglyph</el>
+element provides a way of displaying glyphs for non-Unicode
+characters, and glyph variants for existing Unicode characters; the
+<el>maction</el> element uses attributes from other namespaces to obtain
+implementation-specific parameters; and content markup makes use of
+the <att>definitionURL</att> 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 2.0, 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 <el>mglyph</el> element today may be
+assigned a Unicode codepoint in the future.  At that time,
+representing the character directly by its Unicode codepoint would be
+preferable.</p>
+<p>Because the possibility of future obsolescence is inherent in the
+use of extension mechanisms to facilitate the discussion of new ideas,
+MathML 2.0 makes no conformance requirement concerning the use of
+extension mechanisms, even when alternative standard markup is
+available.  For example, using an <el>mglyph</el> element to represent
+an 'x' is permitted.  However, authors and implementors are
+strongly encouraged to use standard markup whenever possible.
+Similarly, maintainers of documents employing MathML 2.0 extension
+mechanisms are encouraged to monitor relevant standards activity
+(e.g. Unicode, OpenMath, etc) and update documents as more
+standardized markup becomes available.</p> </div4> </div3>
+<div3 id="interf_error"><head>Handling of Errors</head>
+<p>If a MathML-input-<phrase diff="chg">conformant</phrase> 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 <intref ref="presm_merror"><el>merror</el></intref>
+element) in place of invalid expressions.</p>
+<p>MathML-output-<phrase diff="chg">conformant</phrase> applications such as editors and translators may
+choose to generate <el>merror</el> expressions to signal
+errors in their input. This is usually preferable to generating valid, but
+possibly erroneous, MathML.</p>
+</div3>
+<div3 id="interf_unspecified"><head>Attributes for unspecified data</head>
+<p>The MathML attributes described in the MathML specification are
+necessary for presentation and content 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. Although it can be done using
+extensions of the standard DTD, some authors will wish to use
+non-standard attributes to take advantage of renderer-specific
+capabilities while remaining strictly in <phrase diff="chg">conformance</phrase> with the standard
+DTD.</p>
+<p>To allow this, the MathML 1.0 specification <bibref diff="add" ref="MathML1"/>
+allowed the attribute <att>other</att> 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 meantime, however, the development of a general XML namespace
+mechanism has made the use of the <att>other</att>
+attribute obsolete.  In MathML 2.0, the <att>other</att>
+attribute is <intref ref="interf_deprec">deprecated</intref>
+in favor of the use of namespace
+prefixes to identify non-MathML attributes.</p>
+<p>For example, in MathML 1.0, it was recommended that if additional information
+was used in a renderer-specific implementation for the <el>maction</el> element (<specref ref="presm_maction"/>),
+that information should be passed in using the <att>other</att> attribute:</p>
+<eg><![CDATA[
+<maction actiontype="highlight" other="color='#ff0000'"> expression </maction>
+]]></eg>
+<p>In MathML 2.0, a <att>color</att> attribute from another
+namespace would be used:</p>
+<eg><![CDATA[
+<body xmlns:my="http://www.example.com/MathML/extensions">
+...
+<maction actiontype="highlight" my:color="#ff0000"> expression </maction>
+...
+</body>
+]]></eg>
+<p>Note that the intent of allowing non-standard attributes is
+<emph>not</emph> 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>
+</div3>
+</div2>
+<div2 id="interf_future"><head>Future Extensions</head>
+<p>If MathML is to remain useful in the future, it is to be expected
+that MathML will need to be extended and revised in various ways. Some
+of these extensions can be easily foreseen; for example, as work on
+behavioral extensions to CSS proceeds, MathML will likely need to be
+extended as well.</p>
+<p>Similarly, there are several kinds of functionality that are fairly
+obvious candidates for future MathML extensions. These include macros,
+style sheets, and perhaps a general facility for <quote>labeled
+diagrams</quote>. However, there will no doubt be other desirable
+extensions to MathML that will only emerge as MathML is widely used. For
+these extensions, the W3C Math Working Group relies on the extensible
+architecture of XML, and the common sense of the larger Web community.</p>
+<div3><head>Macros and Style Sheets</head>
+<p>The development of style-sheet mechanisms for XML is part of the ongoing
+XML activity of the World Wide Web Consortium. Both XSL and CSS are working
+to incorporate greater support for mathematics.</p>
+<p>In particular, XSL Transformations <bibref ref="XSLT"/> are likely
+to have a large impact on the future development of MathML.  Macros
+have traditionally contributed greatly the usability and effectiveness
+of mathematics encodings.  Further work developing applications of
+XSLT tailored specifically to MathML is clearly called for.</p>
+<p>Some of the possible uses of macro capabilities for MathML include:
+<glist>
+<gitem><label>Abbreviation</label>
+<def><p>One common use of macros is for
+abbreviation. Authors needing to repeat some complicated but constant
+notation can define a macro. This greatly facilitates hand authoring.
+Macros that allow for substitution of parameters facilitate such usage
+even further.</p></def>
+</gitem>
+<gitem><label>Extension of Content Markup</label>
+<def><p>By defining macros for semantic objects, for example a binomial
+coefficient, or a Bessel function, one can in effect extend the content
+markup for MathML.  Such a macro could include an explicit semantic
+binding, or such a binding could be easily added by an external
+application. Narrowly defined disciplines should be able to easily
+introduce standardized content markup by using standard macro packages. For
+example, the OpenMath project could release macro packages for attaching
+OpenMath content markup.</p></def>
+</gitem>
+<gitem><label>Rendering and Style Control</label>
+<def><p>Another basic way in which macros are often used is to provide a
+way of controlling style and rendering behavior by replacing high-level
+macro definitions. This is especially important for controlling the
+rendering behavior of MathML content tags in a context sensitive way. Such
+a macro capability is also necessary to provide a way of attaching
+renderings to user-defined XML extensions to the MathML core.</p></def>
+</gitem>
+<gitem><label>Accessibility</label>
+<def><p>Reader-controlled style sheets are important in providing
+accessibility to MathML. For example, a reader listening to a voice
+renderer might, by default, hear a bit of MathML presentation markup read as
+<quote>D sub x sup 2 of f</quote>. Knowing the context to be multi-variable
+calculus, the reader may wish to use a style sheet or macro package that
+instructs the renderer to render this <el role="starttag">msubsup</el>
+element as <quote>second derivative with respect to x of f</quote>.</p></def>
+</gitem>
+</glist>
+</p>
+</div3>
+<div3><head>XML Extensions to MathML</head>
+<p>The set of elements and attributes specified in the MathML
+specification are necessary for rendering common mathematical expressions.
+It is recognized that not all mathematical notation is covered by this
+set of elements, that new notations are continually invented, and that
+sub-communities within mathematics often have specialized notations;
+and furthermore that the explicit extension of a standard is a
+necessarily slow and conservative process. This implies that the
+MathML standard could never explicitly cover all the presentational
+forms used by every sub-community of authors and readers of
+mathematics, much less encode all mathematical content.</p>
+<p>In order to facilitate the use of MathML by the widest possible
+audience, and to enable its smooth evolution to encompass more
+notational forms and more mathematical content (perhaps eventually
+covered by explicit extensions to the standard), the set of tags and
+attributes is open-ended, in the sense described in this section.</p>
+<p>MathML is described by an XML DTD, which necessarily limits the elements
+and attributes to those occurring in the DTD. Renderers desiring to accept
+non-standard elements or attributes, and authors desiring to include these
+in documents, should accept or produce documents that conform to an
+appropriately extended XML DTD that has the standard MathML DTD
+as a subset.</p>
+<p>MathML<phrase diff="del">-compliant</phrase> renderers are allowed, but not required, to accept
+non-standard elements and attributes, and to render them in any way. If a
+renderer does not accept some or all non-standard tags, it is encouraged
+either to handle them as errors as described above for elements with the
+wrong number of arguments, or to render their arguments as if they were
+arguments to an <el>mrow</el>, in either case rendering all
+standard parts of the input in the normal way.</p>
+</div3>
+</div2>
+</div1>