<semantics>
element<annotation>
element<annotation-xml>
elementannotation-xml
in HTML documentsMathML markup can be combined with other markup languages, and
these mixing constructions are realized by the semantic annotation
elements. The semantic annotation elements provide an important tool
for making associations between alternate representations of an
expression, and for associating semantic properties and other
attributions with a MathML expression. These elements allow
presentation markup and content markup to be combined in several
different ways. One method, known as mixed markup, is to
intersperse content and presentation elements in what is essentially a
single tree. Another method, known as parallel markup,
is to provide both explicit presentation markup and content markup in
a pair of markup expressions, combined by a single semantics
element.
An important concern of MathML is to represent associations between presentation and content markup forms for an expression. Representing associations between MathML expressions and data of other kinds is also important in many contexts. For this reason, MathML provides a general framework for annotation. A MathML expression may be decorated with a sequence of pairs made up of a symbol that indicates the kind of annotation, known as the annotation key, and associated data, known as the annotation value.
The semantics
, annotation
, and
annotation-xml
elements are used together to represent
annotations in MathML. The semantics
element provides the
container for a expression and its annotations. The
annotation
element is the container for text
annotations, and the annotation-xml
element is used for
structured
annotations. The semantics
element contains the expression
being annotated as its first child, followed by a sequence of zero or
more annotation
and/or annotation-xml
elements.
<semantics> <mrow> <mrow> <mi>sin</mi> <mo>⁡<!--FUNCTION APPLICATION--></mo> <mfenced><mi>x</mi></mfenced> </mrow> <mo>+</mo> <mn>5</mn> </mrow> <annotation encoding="application/x-tex"> \sin x + 5 </annotation> <annotation-xml encoding="application/openmath+xml"> <OMA xmlns="http://www.openmath.org/OpenMath"> <OMS cd="arith1" name="plus"/> <OMA><OMS cd="transc1" name="sin"/><OMV name="x"/></OMA> <OMI>5</OMI> </OMA> </annotation-xml> </semantics> |
Note that this example makes use of the namespace extensibility
that is only available in the XML syntax of MathML. If this example is included in an HTML document
then it would be considered invalid and the OpenMath elements would be parsed as
elements un the MathML namespace. See Section 5.2.3.3 Using annotation-xml
in HTML documents for details.
The semantics
element is considered to be both a presentation
element and a content element, and may be used in either context.
All MathML processors should process the semantics
element,
even if they only process one of these two subsets of MathML.
An annotation key specifies the relationship between an expression and an annotation. Many kinds of relationships are possible. Examples include alternate representations, specification or clarification of semantics, type information, rendering hints, and private data intended for specific processors. The annotation key is the primary means by which a processor determines whether or not to process an annotation.
The logical relationship between an expression and an annotation can have a significant impact on the proper processing of the expression. For example, a particular annotation form, called semantic attributions, cannot be ignored without altering the meaning of the annotated expression, at least in some processing contexts. On the other hand, alternate representations do not alter the meaning of an expression, but may alter the presentation of the expression as they are frequently used to provide rendering hints. Still other annotations carry private data or metadata that are useful in a specific context, but do not alter either the semantics or the presentation of the expression.
In MathML 3, annotation keys are defined as symbols in Content Dictionaries, and are specified using
of the cd
and name
attributes on the
annotation
and annotation-xml
elements. For backward
compatibility with MathML 2, an annotation key may also be referenced
using the definitionURL
attribute as an alternative to the
cd
and name
attributes. Further details on
referencing symbols in Content Dictionaries are discussed in Section 4.2.3 Content Symbols <csymbol>
. The symbol definition in a Content Dictionary
for an annotation key may have a role
property. Two
particular roles are relevant for annotations: a role of
"attribution" identifies a generic annotation that can
be ignored without altering the meaning of the annotated term, and a
role of "semantic-attribution" indicates that the annotation
is a semantic annotation, that is, the annotation cannot be ignored
without potentially altering the meaning of the expression.
MathML 3 provides two predefined annotation keys for the most common kinds of annotations: alternate-representation and contentequiv defined in the mathmlkeys content dictionary. The alternate-representation annotation key specifies that the annotation value provides an alternate representation for an expression in some other markup language, and the contentequiv annotation key specifies that the annotation value provides a semantically equivalent alternative for the annotated expression. Further details about the use of these keys is given in the sections below.
The default annotation key is alternate-representation when no annotation key is
explicitly specified on an annotation
or
annotation-xml
element.
Typically, annotation keys specify only the logical nature of the
relationship between an expression and an annotation. The data format
for an annotation is indicated with the encoding
attribute. In MathML 2, the encoding
attribute was the
primary information that a processor could use to determine whether or
not it could understand an annotation. For backward compatibility,
processors are encouraged to examine both the annotation key and
encoding
attribute. In
particular, MathML 2 specified the predefined encoding values
MathML
, MathML-Content
, and
MathML-Presentation
. The MathML
encoding
value is used to indicate an annotation-xml
element contains
a MathML expression. The use of the other values is more specific, as
discussed in following sections.
While the predefined alternate-representation and contentequiv keys cover many common use cases, user communities are encouraged to define and standardize additional content dictionaries as necessary. Annotation keys in user-defined, public Content Dictionaries are preferred over private encoding attribute value conventions, since content dictionaries are more expressive, more open and more maintainable than private encoding values. However, for backward compatibility with MathML 2, the encoding attribute may also be used.
Alternate representation annotations are most often used to provide renderings for an expression, or to provide an equivalent representation in another markup language. In general, alternate representation annotations do not alter the meaning of the annotated expression, but may alter its presentation.
A particularly important case is the use of a presentation MathML
expression to indicate a preferred rendering for a content MathML
expression. This case may be represented by labeling the annotation
with the application/mathml-presentation+xml
value for
the encoding
attribute. For backward compatibility with
MathML 2.0, this case can also be represented with the equivalent
MathML-Presentation
value for the encoding
attribute. Note that when a presentation MathML annotation is
present in a semantics
element, it may be used as the
default rendering of the semantics
element, instead of
the default rendering of the first child.
In the example below, the semantics
element binds together
various alternate representations for a content MathML expression.
The presentation MathML annotation may be used as the
default rendering, while the other annotations give representations
in other markup languages. Since no attribution keys are explicitly
specified, the default annotation key
alternate-representation applies
to each of the annotations.
<semantics> <apply> <plus/> <apply><sin/><ci>x</ci></apply> <cn>5</cn> </apply> <annotation-xml encoding="MathML-Presentation"> <mrow> <mrow> <mi>sin</mi> <mo>⁡<!--FUNCTION APPLICATION--></mo> <mfenced open="(" close=")"><mi>x</mi></mfenced> </mrow> <mo>+</mo> <mn>5</mn> </mrow> </annotation-xml> <annotation encoding="application/x-maple"> sin(x) + 5 </annotation> <annotation encoding="application/vnd.wolfram.mathematica"> Sin[x] + 5 </annotation> <annotation encoding="application/x-tex"> \sin x + 5 </annotation> <annotation-xml encoding="application/openmath+xml"> <OMA xmlns="http://www.openmath.org/OpenMath"> <OMA> <OMS cd="arith1" name="plus"/> <OMA><OMS cd="transc1" name="sin"/><OMV name="x"/></OMA> <OMI>5</OMI> </OMA> </OMA> </annotation-xml> </semantics> |
Note that this example makes use of the namespace extensibility
that is only available in the XML syntax of MathML. If this example is included in an HTML document
then it would be considered invalid and the OpenMath elements would be parsed as
elements un the MathML namespace. See Section 5.2.3.3 Using annotation-xml
in HTML documents for details.
Content equivalent annotations provide additional computational information about an expression. Annotations with the contentequiv key cannot be ignored without potentially changing the behavior of an expression.
An important case arises when a content MathML annotation is used
to disambiguate the meaning of a presentation MathML expression.
This case may be represented by labeling the annotation with the
application/mathml-content+xml
value for the
encoding
attribute. In
MathML 2, this type of annotation was represented with the equivalent
MathML-Content
value for the encoding
attribute,
so processors are urged to support this usage for backward compatibility.
A content MathML annotation, whether in MathML 2 or 3, may be used for
other purposes as well, such as for other kinds of semantic assertions.
Consequently, in MathML 3, the
contentequiv annotation key should
be used to make an explicit assertion that the annotation provides a
definitive content markup equivalent for an expression.
In the example below, an ambiguous presentation MathML expression
is annotated with a MathML-Content
annotation clarifying
its precise meaning.
<semantics> <mrow> <mrow> <mi>a</mi> <mfenced open="(" close=")"> <mrow><mi>x</mi><mo>+</mo><mn>5</mn></mrow> </mfenced> </mrow> </mrow> <annotation-xml cd="mathmlkeys" name="contentequiv" encoding="MathML-Content"> <apply> <ci>a</ci> <apply><plus/><ci>x</ci><cn>5</cn></apply> </apply> </annotation-xml> </semantics> |
In the usual case, each annotation element includes either character data
content (in the case of annotation
) or XML markup data (in the case
of annotation-xml
) that represents the annotation value.
There is no restriction on the type of annotation that may appear within a
semantics
element. For example, an annotation could provide a
TEX encoding, a linear input form for a computer algebra system,
a rendered image, or detailed mathematical type information.
In some cases the alternative children of a semantics
element
are not an essential part of the behavior of the annotated expression, but
may be useful to specialized processors. To enable the availability of
several annotation formats in a more efficient manner, a semantics
element may contain empty annotation
and annotation-xml
elements that provide encoding
and src
attributes
to specify an external location for the annotation value associated with
the annotation. This type of annotation is known as an annotation
reference.
<semantics> <mfrac><mi>a</mi><mrow><mi>a</mi><mo>+</mo><mi>b</mi></mrow></mfrac> <annotation encoding="image/png" src="333/formula56.png"/> <annotation encoding="application/x-maple" src="333/formula56.ms"/> </semantics>
Processing agents that anticipate that consumers of exported markup may not be able to retrieve the external entity referenced by such annotations should request the content of the external entity at the indicated location and replace the annotation with its expanded form.
An annotation reference follows the same rules as for other annotations to determine the annotation key that specifies the relationship between the annotated object and the annotation value.
This section explains the semantic mapping elements semantics
,
annotation
, and annotation-xml
. These elements associate
alternate representations for a presentation or content expression, or
associate semantic or other attributions that may modify the meaning of
the annotated expression.
<semantics>
element
The semantics
element is the container element that
associates annotations with a MathML expression. The
semantics
element has as its first child the expression to be
annotated. Any MathML expression may appear as the first child of the
semantics
element. Subsequent annotation
and
annotation-xml
children enclose the annotations.
An annotation represented in XML is enclosed in an
annotation-xml
element. An annotation represented
in character data is enclosed in an annotation
element.
As noted above, the semantics
element is considered to be
both a presentation element and a content element, since it can act
as either, depending on its content. Consequently, all MathML
processors should process the semantics
element, even if they
process only presentation markup or only content markup.
The default rendering of a semantics
element is the default
rendering of its first child. A renderer may use the information contained
in the annotations to customize its rendering of the annotated element.
<semantics> <mrow> <mrow> <mi>sin</mi> <mo>⁡<!--FUNCTION APPLICATION--></mo> <mfenced><mi>x</mi></mfenced> </mrow> <mo>+</mo> <mn>5</mn> </mrow> <annotation-xml cd="mathmlkeys" name="contentequiv" encoding="MathML-Content"> <apply> <plus/> <apply><sin/><ci>x</ci></apply> <cn>5</cn> </apply> </annotation-xml> <annotation encoding="application/x-tex"> \sin x + 5 </annotation> </semantics> |
Name | values | default |
---|---|---|
definitionURL | URI | none |
The location of an external source for semantic information | ||
encoding | string | none |
The encoding of the external semantic information |
The semantics
element takes the definitionURL
and
encoding
attributes, which reference an external source for some
or all of the semantic information for the annotated element, as modified
by the annotation. The use of these attributes on the semantics
element is deprecated in MathML3.
<annotation>
element
The annotation
element is the container element for a semantic
annotation whose representation is parsed character data in a non-XML
format. The annotation
element should contain the character
data for the annotation, and should not contain XML markup elements.
If the annotation contains one of the XML reserved characters
&
, <
then these characters must
be encoded using an entity reference or
(in the XML syntax)
an XML CDATA
section.
Name | values | default |
---|---|---|
definitionURL | URI | none |
The location of the annotation key symbol | ||
encoding | string | none |
The encoding of the semantic information in the annotation | ||
cd | string | mathmlkeys |
The content dictionary that contains the annotation key symbol | ||
name | string | alternate-representation |
The name of the annotation key symbol | ||
src | URI | none |
The location of an external source for semantic information |
Taken together, the cd
and name
attributes
specify the annotation key symbol, which identifies the relationship
between the annotated element and the annotation, as described in
Section 5.1.1 Annotation elements. The definitionURL
attribute provides an alternate way to reference the annotation key
symbol as a single attribute. If none of these attributes are present,
the annotation key symbol is the symbol
alternate-representation
from the mathmlkeys content dictionary.
The encoding
attribute describes the content type of the
annotation. The value of the encoding
attribute may contain
a media type that identifies the data format for the encoding data. For
data formats that do not have an associated media type, implementors may
choose a self-describing character string to identify their content type.
The src
attribute provides a mechanism to attach external
entities as annotations on MathML expressions.
<annotation encoding="image/png" src="333/formula56.png"/>
The annotation
element is a semantic mapping element that may
only be used as a child of the semantics
element. While there is
no default rendering for the annotation
element, a renderer may
use the information contained in an annotation to customize its rendering
of the annotated element.
<annotation-xml>
element
The annotation-xml
element is the container element for a
semantic annotation whose representation is structured markup. The annotation-xml
element should contain the markup
elements, attributes, and character data for the annotation.
Name | values | default |
---|---|---|
definitionURL | URI | none |
The location of the annotation key symbol | ||
encoding | string | none |
The encoding of the semantic information in the annotation | ||
cd | string | mathmlkeys |
The content dictionary that contains the annotation key symbol | ||
name | string | alternate-representation |
The name of the annotation key symbol | ||
src | URI | none |
The location of an external source for semantic information |
Taken together, the cd
and name
attributes
specify the annotation key symbol, which identifies the relationship
between the annotated element and the annotation, as described in
Section 5.1.1 Annotation elements. The definitionURL
attribute provides an alternate way to reference the annotation key
symbol as a single attribute. If none of these attributes are present,
the annotation key symbol is the symbol
alternate-representation
from the mathmlkeys content dictionary.
The encoding
attribute describes the content type of the
annotation. The value of the encoding
attribute may contain
a media type that identifies the data format for the encoding data. For
data formats that do not have an associated media type, implementors may
choose a self-describing character string to identify their content type.
In particular, as described above and in Section 6.2.4 Names of MathML Encodings, MathML specifies
MathML
, MathML-Presentation
, and
MathML-Content
as predefined values for the
encoding
attribute. Finally, The src
attribute provides a mechanism to attach external XML entities as
annotations on MathML expressions.
<annotation-xml cd="mathmlkeys" name="contentequiv" encoding="MathML-Content"> <apply> <plus/> <apply><sin/><ci>x</ci></apply> <cn>5</cn> </apply> </annotation-xml> <annotation-xml encoding="application/openmath+xml"> <OMA xmlns="http://www.openmath.org/OpenMath"> <OMS cd="arith1" name="plus"/> <OMA><OMS cd="transc1" name="sin"/><OMV name="x"/></OMA> <OMI>5</OMI> </OMA> </annotation-xml>
When the MathML is being parsed as XML and the annotation value is represented in an XML dialect other than MathML, the namespace for the XML markup for the annotation should be identified by means of namespace attributes and/or namespace prefixes on the annotation value. For instance:
<annotation-xml encoding="application/xhtml+xml"> <html xmlns="http://www.w3.org/1999/xhtml"> <head><title>E</title></head> <body> <p>The base of the natural logarithms, approximately 2.71828.</p> </body> </html> </annotation-xml>
The annotation-xml
element is a semantic mapping element that may only be used
as a child of the semantics
element. While there is no default rendering for the
annotation-xml
element, a renderer may use the information contained in an
annotation to customize its rendering of the annotated element.
annotation-xml
in HTML documents
Note that the Namespace extensibility used in the above examples
may not be available if the MathML is not being treated as an XML document. In particular HTML parsers
treat xmlns
attributes as ordinary attributes, so the OpenMath example would be classified as invalid
by an HTML validator. The OpenMath elements would still be parsed as children of the annotation-xml
element, however they would be placed in the MathML namespace. The above examples are not rendered in the HTML version of this specification, to ensure that that document is
a valid HTML5 document.
The details of the HTML parser handling of annotation-xml
is specified in [HTML5] and summarized in Section 6.4.3 Mixing MathML and HTML, however the main differences from the behavior of an XML parser that affect MathML annotations are that the HTML parser
does not treat xmlns
attributes, nor :
in element names as special and has built-in rules determining whether the three "known" namespaces, HTML, SVG or MathML
are used.
If the annotation-xml
has an encoding
attribute that is (ignoring case differences) "text/html" or "annotation/xhtml+xml" then the content is parsed as HTML and
placed (initially) in the HTML namespace.
Otherwise it is parsed as foreign content and parsed in a more XML-like manner (like MathML itself in HTML) in which />
signifies an empty element. Content will be placed in the MathML namespace.
If any recognised HTML element appears in this foreign content annotation the HTML parser will effectively termnate the math
expression, closing all open elements until the math
element is closed, and then process the nested HTML as if it were not inside the math context. Any following MathML elements
will then not render correctly as they are not in a math context, or in the MathML namespace.
These issues mean that the following example is valid whether parsed by an XML or HTML parser:
<math> <semantics> <mi>a</mi> <annotation-xml encoding="text/html"> <span>xxx</span> </annotation-xml> </semantics> <mo>+</mo> <mi>b</mi> </math>
However the if the encoding
attribute is omitted then the expression
is only valid if parsed as XML:
<math> <semantics> <mi>a</mi> <annotation-xml> <span>xxx</span> </annotation-xml> </semantics> <mo>+</mo> <mi>b</mi> </math>
If the above is parsed by an HTML parser it produces a result equivalent to the following invalid input, where the span
element has caused all MathML elements to be prematurely closed. The remaining MathML elements following the span
are no longer contained within <math>
so will be parsed as unknown HTML elements and render incorrectly.
<math xmlns="http://www.w3.org/1998/Math/MathML"> <semantics> <mi>a</mi> <annotation-xml> </annotation-xml> </semantics> </math> <span xmlns="http://www.w3.org/1999/xhtml">xxx</span> <mo xmlns="http://www.w3.org/1999/xhtml">+</mo> <mi xmlns="http://www.w3.org/1999/xhtml">b</mi>
Note here that the HTML span
element has
caused all open MathML elements to be prematurely closed, resulting in
the following MathML elements being treated as unknown HTML elements
as they are no longer descendents of math
. See Section 6.4.3 Mixing MathML and HTML for more details of the parsing of MathML in HTML.
Any use of elements in other vocabularies (such as the OpenMath
examples above) is considered invalid in HTML. If
validity is not a strict requirement it is possible to use such
elements but they will be parsed as elements on the
MathML namespace. Documents SHOULD NOT use namespace
prefixes and element names containing colon (:
) as the
element nodes produced by the HTML parser with have local names
containing a colon, which can not be constructed by a namespace aware
XML parser. Rather than use such foreign annotations, when using an HTML parser
it is better to encode the annotation using the existing
vocabulary. For example as shown in Chapter 4 Content Markup OpenMath
may be encoded faithfuly as Strict Content
MathML. Similarly RDF annotations could be encoded using RDFa
in text/html
annotation or (say) N3 notation in
annotation
rather than using RDF/XML encoding in an
annotation-xml
element.
Presentation markup encodes the notational structure of an expression. Content markup encodes the functional structure of an expression. In certain cases, a particular application of MathML may require a combination of both presentation and content markup. This section describes specific constraints that govern the use of presentation markup within content markup, and vice versa.
Presentation markup may be embedded within content markup so long as the resulting expression retains an unambiguous function application structure. Specifically, presentation markup may only appear in content markup in three ways:
within ci
and cn
token elements
within the csymbol
element
within the semantics
element
Any other presentation markup occurring within content markup is a MathML error. More detailed discussion of these three cases follows:
ci
and cn
are permitted to
contain any sequence of MathML characters (defined in Chapter 7 Characters, Entities and Fonts)
and/or presentation elements. Contiguous blocks of MathML characters in
ci
or cn
elements are treated as if wrapped in
mi
or mn
elements, as appropriate, and the resulting
collection of presentation elements is rendered as if wrapped in an
implicit mrow
element.
csymbol
element.
csymbol
element may contain either MathML characters
interspersed with presentation markup, or content markup. It is a MathML
error for a csymbol
element to contain both presentation and
content elements. When the csymbol
element contains
character data and presentation markup, the same rendering rules that apply
to the token elements ci
and cn
should be used.
semantics
element.
semantics
element is to
provide a mechanism for incorporating arbitrary MathML expressions into
content markup in a semantically meaningful way. In particular, any valid
presentation expression can be embedded in a content expression by placing
it as the first child of a semantics
element. The meaning of this
wrapped expression should be indicated by one or more annotation elements
also contained in the semantics
element.
Content markup may be embedded within presentation markup so long as the resulting expression has an unambiguous rendering. That is, it must be possible, in principle, to produce a presentation markup fragment for each content markup fragment that appears in the combined expression. The replacement of each content markup fragment by its corresponding presentation markup should produce a well-formed presentation markup expression. A presentation engine should then be able to process this presentation expression without reference to the content markup bits included in the original expression.
In general, this constraint means that each embedded content expression
must be well-formed, as a content expression, and must be able to stand
alone outside the context of any containing content markup element. As
a result, the following content elements may not appear as an immediate
child of a presentation element:
annotation
, annotation-xml
,
bvar
, condition
, degree
,
logbase
, lowlimit
, uplimit
.
In addition, within presentation markup, content markup may not appear within presentation token elements.
Some applications are able to use both presentation
and content information. Parallel markup is a way to
combine two or more markup trees for the same mathematical expression.
Parallel markup is achieved with the semantics
element.
Parallel markup for an expression may appear on its own, or as part
of a larger content or presentation tree.
In many cases, the goal is to provide presentation markup and content
markup for a mathematical expression as a whole.
A single semantics
element may be used to pair two markup trees,
where one child element provides the presentation markup, and the
other child element provides the content markup.
The following example encodes the Boolean arithmetic expression (a+b)(c+d) in this way.
<semantics> <mrow> <mrow><mo>(</mo><mi>a</mi> <mo>+</mo> <mi>b</mi><mo>)</mo></mrow> <mo>⁢<!--INVISIBLE TIMES--></mo> <mrow><mo>(</mo><mi>c</mi> <mo>+</mo> <mi>d</mi><mo>)</mo></mrow> </mrow> <annotation-xml encoding="MathML-Content"> <apply><and/> <apply><xor/><ci>a</ci> <ci>b</ci></apply> <apply><xor/><ci>c</ci> <ci>d</ci></apply> </apply> </annotation-xml> </semantics> |
Note that the above markup annotates the presentation markup as
the first child element, with the content markup as part of the
annotation-xml
element. An equivalent form could be given
that annotates the content markup as the first child element, with
the presentation markup as part of the annotation-xml
element.
To accommodate applications that must process sub-expressions of large
objects, MathML supports cross-references between the branches of a
semantics
element to identify corresponding sub-structures.
These cross-references are established by the use of the id
and xref
attributes within a semantics
element.
This application of the id
and xref
attributes within
a semantics
element should be viewed as best practice to enable
a recipient to select arbitrary sub-expressions in each alternative
branch of a semantics
element. The id
and
xref
attributes may be placed on MathML elements of any type.
The following example demonstrates cross-references for the Boolean arithmetic expression (a+b)(c+d).
<semantics> <mrow id="E"> <mrow id="E.1"> <mo id="E.1.1">(</mo> <mi id="E.1.2">a</mi> <mo id="E.1.3">+</mo> <mi id="E.1.4">b</mi> <mo id="E.1.5">)</mo> </mrow> <mo id="E.2">⁢<!--INVISIBLE TIMES--></mo> <mrow id="E.3"> <mo id="E.3.1">(</mo> <mi id="E.3.2">c</mi> <mo id="E.3.3">+</mo> <mi id="E.3.4">d</mi> <mo id="E.3.5">)</mo> </mrow> </mrow> <annotation-xml encoding="MathML-Content"> <apply xref="E"> <and xref="E.2"/> <apply xref="E.1"> <xor xref="E.1.3"/><ci xref="E.1.2">a</ci><ci xref="E.1.4">b</ci> </apply> <apply xref="E.3"> <xor xref="E.3.3"/><ci xref="E.3.2">c</ci><ci xref="E.3.4">d</ci> </apply> </apply> </annotation-xml> </semantics> |
An id
attribute and associated xref
attributes
that appear within the same semantics
element establish the
cross-references between corresponding sub-expressions.
For parallel markup, all of the id
attributes referenced by any xref
attribute should be in the same branch of an enclosing
semantics
element. This constraint guarantees that the
cross-references do not create unintentional cycles. This restriction
does not exclude the use of id
attributes within
other branches of the enclosing semantics
element. It does,
however, exclude references to these other id
attributes
originating from the same semantics
element.
There is no restriction on which branch of the semantics
element
may contain the destination id
attributes. It is up to the
application to determine which branch to use.
In general, there will not be a one-to-one correspondence between nodes
in parallel branches. For example, a presentation tree may contain elements,
such as parentheses, that have no correspondents in the content tree. It is
therefore often useful to put the id
attributes on the branch with
the finest-grained node structure. Then all of the other branches will have
xref
attributes to some subset of the id
attributes.
In absence of other criteria, the first branch of the semantics
element is a sensible choice to contain the id
attributes.
Applications that add or remove annotations will then not have to re-assign
these attributes as the annotations change.
In general, the use of id
and xref
attributes allows
a full correspondence between sub-expressions to be given in text that is
at most a constant factor larger than the original. The direction of the
references should not be taken to imply that sub-expression selection is
intended to be permitted only on one child of the semantics
element.
It is equally feasible to select a subtree in any branch and
to recover the corresponding subtrees of the other branches.
Parallel markup with cross-references may be used in any XML-encoded branch of the semantic annotations, as shown by the following example where the Boolean expression of the previous section is annotated with OpenMath markup that includes cross-references:
<semantics> <mrow id="EE"> <mrow id="EE.1"> <mo id="EE.1.1">(</mo> <mi id="EE.1.2">a</mi> <mo id="EE.1.3">+</mo> <mi id="EE.1.4">b</mi> <mo id="EE.1.5">)</mo> </mrow> <mo id="EE.2">⁢<!--INVISIBLE TIMES--></mo> <mrow id="EE.3"> <mo id="EE.3.1">(</mo> <mi id="EE.3.2">c</mi> <mo id="EE.3.3">+</mo> <mi id="EE.3.4">d</mi> <mo id="EE.3.5">)</mo> </mrow> </mrow> <annotation-xml encoding="MathML-Content"> <apply xref="EE"> <and xref="EE.2"/> <apply xref="EE.1"> <xor xref="EE.1.3"/><ci xref="EE.1.2">a</ci><ci xref="EE.1.4">b</ci> </apply> <apply xref="EE.3"> <xor xref="EE.3.3"/><ci xref="EE.3.2">c</ci><ci xref="EE.3.4">d</ci> </apply> </apply> </annotation-xml> <annotation-xml encoding="application/openmath+xml"> <om:OMA xmlns:om="http://www.openmath.org/OpenMath" href="EE"> <om:OMS name="and" cd="logic1" href="EE.2"/> <om:OMA href="EE.1"> <om:OMS name="xor" cd="logic1" href="EE.1.3"/> <om:OMV name="a" href="EE.1.2"/> <om:OMV name="b" href="EE.1.4"/> </om:OMA> <om:OMA href="EE.3"> <om:OMS name="xor" cd="logic1" href="EE.3.3"/> <om:OMV name="c" href="EE.3.2"/> <om:OMV name="d" href="EE.3.4"/> </om:OMA> </om:OMA> </annotation-xml> </semantics> |
Here OMA
, OMS
and OMV
are elements defined in the OpenMath
standard for representing application, symbol, and variable, respectively.
The references from the OpenMath annotation are given by the
href
attributes.
As noted above, the use of namespaces other than MathML, SVG
or HTML within annotation-xml
is not considered valid in the HTML syntax.
Use of colons and namespace-prefixed element names should be avoided
as the HTML parser will generate nodes with local name om:OMA
(for example), and such nodes can not be constructed by a namespace-aware XML parser.