Open AdamSobieski opened 5 years ago
This suggestion seems to be a breaking change from all previous versions of MathML, where <semantics>
by default displays its first argument. The use cases of supplying alternative presentations and metadata all seem to be covered by the existing <semantics>
given suitable annotation-xml
labels.
A simple workaround appears to be to rename <semantics>
to <content>
. As per:
<math id="eq1">
<presentation>
<annotation-xml encoding="application/xhtml+xml">...</annotation-xml>
<annotation-xml encoding="application/svg+xml">...</annotation-xml>
<annotation encoding="image/png" src="data:..." />
<annotation-xml encoding="application/mathml-presentation+xml">...</annotation-xml>
</presentation>
<content>
<annotation-xml encoding="application/openmath+xml">...</annotation-xml>
<annotation-xml encoding="application/mathml-content+xml">...</annotation-xml>
</content>
</math>
We could also map MathML’s <semantics>
to <annotations>
as per the second example in https://github.com/mathml-refresh/mathml/issues/80.
Instead of using the first child element or annotation of MathML’s <semantics>
, the proposal includes that users’ preferences, e.g. browser settings, would be of use in selecting from alternatives, resembling, perhaps, MathJax's context menu settings.
There is also a proposed q
or quality attribute where authors could specify the relative quality of alternatives. As per:
<math id="eq1">
<presentation>
<annotation-xml q="0.9" encoding="application/xhtml+xml">...</annotation-xml>
<annotation-xml q="0.9" encoding="application/svg+xml">...</annotation-xml>
<annotation q="0.9" encoding="image/png" src="data:..." />
<annotation-xml q="1.0" encoding="application/mathml-presentation+xml">...</annotation-xml>
</presentation>
</math>
These particulars would be detailed in the specification of a content selection algorithm.
There would be a very high cost to these proposals (changing the HTML5 parser and incompatible with all existing MathML tools) and I haven't yet seen any examples that are not just a re-arrangement of the MathML3 <semantics>
markup. If you used the existing <semantics>
markup then in some cases you may need to follow some conventions on the attributes on annotation-xml elements to distinguish the cases that you are distinguishing with <presentation
but in most cases it would seem to just be a simple re-write unless I am missing something? The example you post above is not understood by any MathML system but
<math id="eq1">
<semantics>
<mrow> some default presentation</mrow>
<annotation-xml encoding="application/xhtml+xml">...</annotation-xml>
<annotation-xml encoding="application/svg+xml">...</annotation-xml>
<annotation encoding="image/png" src="data:..." />
<annotation-xml encoding="application/mathml-presentation+xml">...</annotation-xml>
<annotation-xml encoding="application/openmath+xml">...</annotation-xml>
<annotation-xml encoding="application/mathml-content+xml">...</annotation-xml>
</semantics>
</math>
Is understood by all MathML systems going back to version 1.0.
In this case I don't see any gain in functionality to compensate for the loss of interoperability.
Beyond purely syntactic topics, the options differ with respect to selecting content from alternatives – with respect to content selection algorithms. Content selection algorithms can be a gain in functionality.
There are three syntactic options under discussion. Option 1 is MathML3, option 2 was introduced in this issue (https://github.com/mathml-refresh/mathml/issues/68) and option 3 was introduced in issue https://github.com/mathml-refresh/mathml/issues/80.
There are three options for distinguishing between varieties of annotations:
cd
and name
attributes on <annotation>
and <annotation-xml>
elements to distinguish between varieties of annotations.<presentation>
, <semantics>
(or <content>
), <metadata>
and <other>
elements to distinguish between varieties of annotations.kind
attribute on <annotation>
and/or <annotation-xml>
elements to distinguish between varieties of annotations.There are two options for selecting content from alternatives:
<semantics>
element as the default presentation content.There are at least two mental models of mathematical expressions as represented by markup:
<semantics>
element is the mathematical expression which is annotated by subsequent <annotation>
and <annotation-xml>
elements.<math>
element, in its entirety, represents a mathematical expression and it can contain alternatives for presentation, semantics, metadata as well as other types of content.Option | Distinguishing Varieties of Annotations | Content Selection |
---|---|---|
MathML3 | uses cd and name attributes on <annotation> and <annotation-xml> elementsSee also: MathML3 Chapter 5, https://www.openmath.org/cd/mathmlkeys |
select first child of <semantics> element as presentation |
Option 2 (https://github.com/mathml-refresh/mathml/issues/68) | uses <presentation> , <semantics> (or <content> ), <metadata> and <other> elements |
a content selection algorithm |
Option 3 (https://github.com/mathml-refresh/mathml/issues/80) | uses kind attribute on <annotation> and <annotation-xml> elements |
a content selection algorithm |
<math id="eq1">
<semantics>
<mrow>some default presentation</mrow>
<annotation-xml cd="mathmlkeys" name="alternate-representation" encoding="application/xhtml+xml">...</annotation-xml>
<annotation-xml cd="mathmlkeys" name="alternate-representation" encoding="application/svg+xml">...</annotation-xml>
<annotation cd="mathmlkeys" name="alternate-representation" encoding="image/png" src="data:..." />
<annotation-xml cd="mathmlkeys" name="contentequiv" encoding="application/openmath+xml">...</annotation-xml>
<annotation-xml cd="mathmlkeys" name="contentequiv" encoding="application/mathml-content+xml">...</annotation-xml>
</semantics>
</math>
Question: If a Web browser, EPUB reader, or other software cannot render MathML presentation markup, is it specified what the software should do when provided with presentation alternatives? Is it specified that, for example, the software should iterate through the sequence of presentation alternatives? That is, for the above example, is it specified that a software should consider, in sequence: the MathML presentation content, the XHTML content, the SVG content, then the PNG content, as they occur in the XML-based sequence, until it finds a presentation alternative which it can render?
<math id="eq1">
<presentation>
<annotation-xml encoding="application/xhtml+xml">...</annotation-xml>
<annotation-xml encoding="application/svg+xml">...</annotation-xml>
<annotation encoding="image/png" src="data:..." />
<annotation-xml encoding="application/mathml-presentation+xml">...</annotation-xml>
</presentation>
<content>
<annotation-xml encoding="application/openmath+xml">...</annotation-xml>
<annotation-xml encoding="application/mathml-content+xml">...</annotation-xml>
<annotation-xml encoding="application/rdf+xml">...</annotation-xml>
</content>
<metadata>
<annotation-xml encoding="application/rdf+xml">...</annotation-xml>
<annotation encoding="application/json+ld">...</annotation>
</metadata>
<other rel="http://www.example.com/semantic-uri/">
<annotation-xml encoding="...">...</annotation-xml>
</other>
</math>
kind
attribute<math id="eq1">
<annotations>
<annotation-xml kind="presentation" encoding="application/xhtml+xml">...</annotation-xml>
<annotation-xml kind="presentation" encoding="application/svg+xml">...</annotation-xml>
<annotation kind="presentation" encoding="image/png" src="data:..." />
<annotation-xml kind="presentation" encoding="application/mathml-presentation+xml">...</annotation-xml>
<annotation-xml kind="semantics" encoding="application/openmath+xml">...</annotation-xml>
<annotation-xml kind="semantics" encoding="application/mathml-content+xml">...</annotation-xml>
<annotation-xml kind="semantics" encoding="application/rdf+xml">...</annotation-xml>
<annotation-xml kind="metadata" encoding="application/rdf+xml">...</annotation-xml>
<annotation kind="metadata" encoding="application/json+ld">...</annotation>
<annotation-xml kind="other" rel="http://www.example.com/semantic-uri/" encoding="...">...</annotation-xml>
</annotations>
</math>
Content selection algorithms are approaches to selecting resources from multiple alternatives. Examples of content selection algorithms include HTTP content negotiation. In the context of mathematical markup, content selection algorithms can be advantageous to authors and to users.
Content selection algorithms can allow authors to provide alternative presentation, semantics, metadata and other varieties of resources which can facilitate mathematics rendering and utilization. Content selection algorithms can allow users to configure their browsers, EPUB readers or other software to their preferences. Users can, similarly, configure MathJax to select between rendering modes: CommonHTML, MathML, HTML-CSS and SVG.
Should an author provide only one presentation content, then that content is to be selected. When two or more presentation alternatives are provided by an author, instead of automatically selecting the first alternative, we can utilize a content selection algorithm.
<math id="eq1">
<presentation>
<annotation-xml encoding="application/xhtml+xml">...</annotation-xml>
<annotation-xml encoding="application/mathml-presentation+xml">...</annotation-xml>
</presentation>
</math>
The encoding
, lang
, notation
, media
and q
attributes could be utilized on <annotation>
and <annotation-xml>
elements to describe inline or remote resources so as to facilitate algorithmic approaches to content selection. In the above example, while the MathML presentation content is the second XML child of the <presentation>
element, a software may still select it over the XHTML content.
In HTML5, multimedia content selection is facilitated via the <source>
element.
In HTTP content negotiation, an example of a content selection algorithm, a number of HTTP request headers are utilized:
Accept-Language: de; q=1.0, en; q=0.5
Accept: text/html; q=1.0, text/*; q=0.8, image/gif; q=0.6, image/jpeg; q=0.6, image/*; q=0.5, */*; q=0.1
These HTTP headers correspond with browser and user settings and configuration. Such settings and configuration could interplay with the content expressible with syntactic options 2 and 3 when selecting content from alternatives.
Furthermore, via a q
attribute, authors could specify the relative quality of alternatives or resources.
<math id="eq1">
<presentation>
<annotation-xml q="0.9" encoding="application/xhtml+xml">...</annotation-xml>
<annotation-xml q="1.0" encoding="application/mathml-presentation+xml">...</annotation-xml>
</presentation>
</math>
Custom styling of presentation content in these scenarios is discussed briefly in issue https://github.com/mathml-refresh/mathml/issues/78. The gist is that a :selected
pseudo-class can be utilized to indicate the specific <annotation>
or <annotation-xml>
element selected by the browser, EPUB reader, or other software.
Option 2 styling ideas:
#eq1 > presentation > annotation-xml:selected >> mrow
Option 3 styling ideas:
#eq1 > annotations > annotation-xml[kind='presentation']:selected >> mrow
Beyond purely syntactic topics, the options differ with respect to selecting content from alternatives – with respect to content selection algorithms. Content selection algorithms can be a gain in functionality.
Content selection algorithms can allow authors to provide alternative presentation, semantics, metadata and other varieties of resources which can facilitate mathematics rendering and utilization. Content selection algorithms can allow users to configure their browsers, EPUB readers or other software to their preferences. Users can, similarly, configure MathJax to select between rendering modes: CommonHTML, MathML, HTML-CSS and SVG.
The content selection algorithms which can accompany syntactic options 2 and 3 are new functionality for MathML and may provide value – may provide benefit – which offsets the cost of breaking changes during the versioning of MathML.
Sorry I still see no functionality gain in the proposed syntactic changes. With the mathml markup as defined in mathml 1-3 the rendering as first child is only a default, the rendering agent can opt to use an svg or presentation or image annotation instead as the source for the rendering, the suggestion above proposes adding the q attribute to steer that choice, but that attribute could be proposed without the disruptive change to an incompatible syntax.
is the same as the mathml3 below apart from the added q attribute
Absolutely. The encoding
, lang
, media
and q
attributes are drawn from HTML5 multimedia content selection and HTTP content negotiation. The notation
attribute is presently theoretical. The encoding
, lang
, notation
, media
and q
attributes could be utilized on <annotation>
and <annotation-xml>
elements for each of the indicated syntactic options. Any or all of the aforementioned attributes could adorn <annotation>
and <annotation-xml>
elements in a MathML3-based syntax, which we could refer to as option 4 – there now being at least four options.
<math id="eq1">
<semantics>
<mrow>default</mrow>
<annotation-xml q="0.9" encoding="application/xhtml+xml">...</annotation-xml>
<annotation-xml q="1.0" encoding="application/mathml-presentation+xml">...</annotation-xml>
</semantics>
</math>
<math id="eq1">
<semantics>
<mrow>default</mrow>
<annotation-xml q="1.0" lang="fr" encoding="application/mathml-presentation+xml">...</annotation-xml>
</semantics>
</math>
<math id="eq1">
<semantics>
<mrow>default</mrow>
<annotation-xml q="0.9" encoding="application/xhtml+xml">...</annotation-xml>
<annotation-xml q="1.0" encoding="application/mathml-presentation+xml">...</annotation-xml>
<annotation q="0.2" media="(resolution >= 2dppx)" encoding="image/png" src="eq1-hi-res.png" />
<annotation q="0.2" media="(resolution < 2dppx)" encoding="image/png" src="eq1-lo-res.png" />
</semantics>
</math>
Furthermore, space-delimited values for encoding
and lang
could be utilized in MathML3-based syntaxes with a pattern
attribute which utilizes string interpolation.
<math id="eq1">
<semantics>
<mrow>default</mrow>
<annotation-xml q="0.9" lang="en fr es de" encoding="application/xhtml+xml" pattern="math.php?language={lang}&encoding=application%2Fxhtml+xml" />
<annotation-xml q="1.0" lang="en fr es de" encoding="application/mathml-presentation+xml" pattern="math.php?language={lang}&encoding=application%2Fmathml-presentation+xml" />
</semantics>
</math>
It would, then, be a matter of describing the content selection algorithms with which to select resources from alternatives. One option is to consider utilization of HTTP content negotiation. HTTP request headers could be of use, as per:
Accept-Language: en; q=1.0, fr; q=0.8, es; q=0.8, de; q=0.8
Accept: application/mathml-presentation+xml; q=1.0, application/xhtml+xml; q=0.8, application/svg+xml; q=0.8, image/png; q=0.2, image/*; q=0.2, */*; q=0.1
These HTTP headers, possibly string inputs to content selection algorithms, could be of use for indicating software and user settings and configuration when selecting described resources from alternatives.
I don't think the other options should be considered. The costs of introducing incompatible element markup which has no fallback in every existing MathML system compared to a functionally equivalent use of some additional attributes which while technically invalid in mathml3 are likely to be silently accepted in all existing systems is simply too high.
Sounds good. I can make use of backwards-compatible syntaxes for brainstorming and examples. I also updated issue https://github.com/mathml-refresh/mathml/issues/79.
By adding one attribute to the <semantics>
element, default
, the above ideas and examples can be expressed in a backwards-compatible syntax. The default
attribute has as its possible values: “first” and “none”. The default value of the default
attribute is “first”.
The value of “first” for the default
attribute indicates that the behavior of the <semantics>
element is the MathML3 behavior, where the first child element is the default presentation content. The value of “none” for the default
attribute indicates that no child element of the <semantics>
element is intended as default content.
Algorithms for selecting “presentation”, “semantic”, “metadata” or “other” content from alternatives may resemble agent-driven or reactive content negotiation.
Together with the encoding
attribute, lang
, notation
, media
, and q
attributes can facilitate content selection from alternatives in a manner which resembles HTTP-based content negotiation for mathematical content.
See also: MathML3 <annotation>
element
See also: MathML3 <annotation-xml>
element
See also: HTML5 <source>
element
For scenarios where natural language is utilized in the “presentation” annotation content, a BCP47 language attribute can adorn annotation markup and “presentation” annotations can also be described in expression “metadata”.
<math id="eq1">
<semantics default="none">
<annotation-xml lang="en" encoding="application/mathml-presentation+xml">...</annotation-xml>
<annotation-xml lang="fr" encoding="application/mathml-presentation+xml">...</annotation-xml>
</semantics>
</math>
<math id="eq1">
<semantics default="none">
<annotation-xml lang="en" encoding="application/mathml-presentation+xml">...</annotation-xml>
<annotation-xml lang="fr" encoding="application/mathml-presentation+xml">...</annotation-xml>
<annotation-xml name="contentequiv" encoding="application/mathml-content+xml">...</annotation-xml>
<annotation-xml name="metadata" encoding="application/rdf+xml">...</annotation-xml>
</semantics>
</math>
“Presentation” annotations can include content spanning multiple modalities, e.g. SSML or audio, and “presentation” annotations can also be described in expression “metadata”.
<math id="eq1">
<semantics default="none">
<annotation-xml lang="en" encoding="application/mathml-presentation+xml">...</annotation-xml>
<annotation-xml lang="fr" encoding="application/mathml-presentation+xml">...</annotation-xml>
<annotation-xml lang="en" encoding="application/ssml+xml">...</annotation-xml>
<annotation-xml lang="fr" encoding="application/ssml+xml">...</annotation-xml>
<annotation lang="en" encoding="audio/mpeg" src="..." />
<annotation lang="fr" encoding="audio/mpeg" src="..." />
<annotation-xml name="contentequiv" encoding="application/mathml-content+xml">...</annotation-xml>
<annotation-xml name="metadata" encoding="application/rdf+xml">...</annotation-xml>
</semantics>
</math>
Might the values of a notation
attribute be the display names of notations, URI’s, or encoded strings resembling BCP47? Might the values of a notation
attribute be, instead, lists of settings and their values resembling the style
attribute?
<math id="eq1">
<semantics default="none">
<annotation-xml notation="Notation 1" encoding="application/mathml-presentation+xml">...</annotation-xml>
<annotation-xml notation="Notation 2" encoding="application/mathml-presentation+xml">...</annotation-xml>
<annotation-xml notation="Notation 3" encoding="application/mathml-presentation+xml">...</annotation-xml>
</semantics>
</math>
The following example shows a combination of multiple presentation formats with multiple notations.
<math id="eq1">
<semantics default="none">
<annotation-xml notation="Notation 1" encoding="application/xhtml+xml">...</annotation-xml>
<annotation-xml notation="Notation 2" encoding="application/xhtml+xml">...</annotation-xml>
<annotation-xml notation="Notation 3" encoding="application/xhtml+xml">...</annotation-xml>
<annotation-xml notation="Notation 1" encoding="application/svg+xml">...</annotation-xml>
<annotation-xml notation="Notation 2" encoding="application/svg+xml">...</annotation-xml>
<annotation-xml notation="Notation 3" encoding="application/svg+xml">...</annotation-xml>
<annotation notation="Notation 1" encoding="image/png" src="data:..." />
<annotation notation="Notation 2" encoding="image/png" src="data:..." />
<annotation notation="Notation 3" encoding="image/png" src="data:..." />
<annotation-xml notation="Notation 1" encoding="application/mathml-presentation+xml">...</annotation-xml>
<annotation-xml notation="Notation 2" encoding="application/mathml-presentation+xml">...</annotation-xml>
<annotation-xml notation="Notation 3" encoding="application/mathml-presentation+xml">...</annotation-xml>
<annotation-xml name="contentequiv" encoding="application/openmath+xml">...</annotation-xml>
<annotation-xml name="contentequiv" encoding="application/mathml-content+xml">...</annotation-xml>
<annotation-xml name="metadata" encoding="application/rdf+xml">...</annotation-xml>
</semantics>
</math>
A media
attribute can facilitate the use of media queries. “Presentation” annotations can also be described in expression “metadata”.
<math id="eq1">
<semantics default="none">
<annotation-xml encoding="application/mathml-presentation+xml">...</annotation-xml>
<annotation media="(resolution >= 2dppx)" encoding="image/png" src="eq1-high.png" />
<annotation media="(resolution < 2dppx)" encoding="image/png" src="eq1-low.png" />
<annotation-xml media="speech" encoding="application/ssml+xml">...</annotation-xml>
<annotation media="speech" encoding="audio/mpeg" src="..." />
<annotation-xml name="metadata" encoding="application/rdf+xml">...</annotation-xml>
</semantics>
</math>
<math id="eq1">
<semantics default="none">
<annotation-xml q="0.9" encoding="application/xhtml+xml">...</annotation-xml>
<annotation-xml q="0.9" encoding="application/svg+xml">...</annotation-xml>
<annotation q="0.9" encoding="image/png" src="data:..." />
<annotation-xml q="1.0" encoding="application/mathml-presentation+xml">...</annotation-xml>
</semantics>
</math>
<math id="eq1">
<semantics default="none">
<annotation-xml encoding="application/xhtml+xml" src="eq1.xhtml" />
<annotation-xml encoding="application/svg+xml" src="eq1.svg" />
<annotation encoding="image/png" src="eq1.png" />
<annotation-xml encoding="application/mathml-presentation+xml" src="eq1.mmlp" />
<annotation-xml name="contentequiv" encoding="application/openmath+xml" src="eq1.om" />
<annotation-xml name="contentequiv" encoding="application/mathml-content+xml" src="eq1.mmlc" />
</semantics>
</math>
Described are uses of a pattern
attribute for providing string templates with which string interpolation algorithms can produce values for src
attributes on <annotation>
and <annotation-xml>
elements.
A pattern
attribute could be of use for specifying string interpolation placeholders in URL query strings.
<math id="eq1">
<semantics default="none">
<annotation-xml pattern="math.php?equation=eq1&type={encoding}&language={lang}" />
</semantics>
</math>
A pattern
attribute could also be of use for specifying string interpolation placeholders in file names and paths.
<math id="eq1">
<semantics default="none">
<annotation-xml encoding="application/mathml-presentation+xml" pattern="eq1-{lang}.mmlp" />
</semantics>
</math>
Media queries could be utilized via a media
attribute.
<math id="eq1">
<semantics default="none">
<annotation media="(resolution >= 2dppx)" encoding="image/png" pattern="math.php?equation=eq1&type=image%2Fpng&notation={notation}&resolution=high" />
<annotation media="(resolution < 2dppx)" encoding="image/png" pattern="math.php?equation=eq1&type=image%2Fpng&notation={notation}&resolution=low" />
</semantics>
</math>
Those <annotation-xml>
and <annotation>
elements with encoding
, lang
, notation
, media
, or q
attributes could be described as “more specific” and thus to be utilized first when matching for content selection.
<math id="eq1">
<semantics default="none">
<annotation-xml encoding="application/ssml+xml" pattern="math-synthesis.php?equation=eq1&language={lang}" />
<annotation encoding="audio/mpeg" pattern="math-audio.php?equation=eq1&type=audio%2Fmpeg&language={lang}" />
<annotation-xml pattern="math.php?equation=eq1&type={encoding}&language={lang}&notation={notation}" />
</semantics>
</math>
The encoding
attribute, the lang
attribute and possibly the notation
attribute could be utilized with multiple, delimited (e.g. space delimited) values for specifying when a pattern is valid.
<math id="eq1">
<semantics default="none">
<annotation-xml encoding="application/mathml-presentation+xml application/xhtml+xml application/svg+xml" lang="en fr es de" pattern="math.php?equation=eq1&type={encoding}&language={lang}&notation={notation}" />
<annotation encoding="image/png" lang="en fr es de" pattern="math.php?equation=eq1&type={encoding}&language={lang}&notation={notation}" />
</semantics>
</math>
<math id="eq1">
<semantics default="none">
<annotation-xml encoding="application/mathml-presentation+xml" lang="en fr es de" pattern="eq1-{lang}.mmlp" />
</semantics>
</math>
There is a caveat to delimiting MIME types with spaces in that MIME types can have parameters and spaces could exist between MIME types and their parameters as well as in the quoted string values of their parameters, for instance when specifying codecs.
See: RFC 7231 § 3.1.1.1, RFC 6381
MIME types with spaces can be observed in the HTML5 specification, e.g. HTML5 <source>
element § Example 18.
audio/ogg; codecs=speex
If spaces are desired to delimit sets or lists of MIME types, then collapsing spaces in MIME types, including those with complex parameter values, e.g. codecs, would be required.
<math id="eq1">
<semantics default="none">
<annotation encoding="audio/ogg;codecs=speex audio/mpeg" pattern="math-audio.php?equation=eq1&type={encoding}&language={lang}" />
</semantics>
</math>
A fuller set of placeholders can be created for URL string interpolation. For example, a customizable filename {extension}
placeholder can be derived from the encoding selected.
<math id="eq1">
<semantics default="none">
<annotation-xml encoding="application/mathml-presentation+xml application/xhtml+xml application/svg+xml" lang="en fr es de" pattern="eq1-{lang}.{extension}" />
</semantics>
</math>
See also: printf
format string
See also: String interpolation
See also: Template processing
Remote mathematical expressions could be facilitated via a src
attribute on <math>
elements.
<math id="eq1" src="eq1.mml" />
Additionally, HTML5 <img>
and <object>
elements could be of use.
<img id="eq1" src="eq1.mml" />
<object id="eq1" data="eq1.mml" type="application/mathml+xml" />
See also: HTML5 <img>
element
See also: HTML5 <object>
element
I don't understand the use case for the suggested default attribute. There has to be a default specified somehow. Perhaps you are off line or the servers specified in the annotations are down, presumably the default if no annotation can be used and no default is specified is to act like an empty mrow, so the suggested
<semantics default="none">
<xml-annotation>...
seems to be identical to the existing
<semantics>
<mrow/>
<xml-annotation>...
The idea of the default
attribute, which could perhaps be the default-rendering
attribute, is to toggle the default rendering behavior of the <semantics>
element.
The MathML3 specification states that: “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.” – MathML3 <semantics>
element
As I understand it, the first child element of a <semantics>
element could be an element like <mrow>
or an <annotation>
or <annotation-xml>
element.
As I understand it, the above quotation means that a renderer should first attempt to render the first child element of a <semantics>
element. We can further specify for MathML4 that, if a renderer cannot render that default rendering, then it should attempt to render “alternate-representation” annotations as fallback renderings. For MathML4, we can describe the means of selecting from fallback renderings – the content selection algorithm.
With a default
attribute, the above behavior would be the default='first'
behavior which is intended by the author when either the author omits the default
attribute or provides it with the value of “first”.
There are also the use cases where there is no intended default rendering and the desired behavior of a renderer is to utilize the content selection algorithm to select renderings from a provided set of “alternate-representation” annotations.
In summary, with the default behavior of default='first'
, the author intends that the renderer should:
And, by providing the default
attribute with the value of “none”, the default='none'
behavior, the author intends that the renderer should:
@AdamSobieski
As I understand it, the above quotation means that a renderer should first attempt to render the first child element of a
<semantics>
element.
No, that is a misunderstanding. It is the default rendering for use if other options are not available, so examples given in previous specs included semantics elements with svg annotations, with the intention being that an svg capable system use the svg rather than the first child. Similarly annotations of presentation mathml which a system that can render presentation mathml but not the first child (which may be content mathml) should use for rendering.
So already as specified in mathml3 a system can use any of the annotations specified in a semantics element as the rendering.
You are suggesting the addition of some attributes to provide hints on the preference order on which annotation to use whereas mathml3 leaves that system-defined, but the default attribute adds nothing.
Ah, now I understand. There could be a use for a different variety of toggle.
"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."
– MathML3 <semantics>
element
We would want to be able to toggle to a behavior briefly described by contrasting with the above description:
The <semantics>
element is the container element for types of data distinguished by annotation keys. The first child is not the expression to be annotated. All of the child elements are <annotation>
or <annotation-xml>
elements. The element has no default rendering.
Perhaps annotated='first'
could be the MathML3 behavior and annotated='none'
could be the toggled-to behavior. annotated='first'
would be the default value for the attribute, the value if the attribute is omitted.
annotated='first'
:
<math id="eq1">
<semantics>
<mrow>annotated, default</mrow>
<annotation-xml>annotating</annotation-xml>
<annotation-xml>annotating</annotation-xml>
</semantics>
</math>
annotated='none'
:
<math id="eq1">
<semantics annotated='none'>
<annotation-xml>data</annotation-xml>
<annotation-xml>data</annotation-xml>
<!-- also, there is no default -->
</semantics>
</math>
What do you think?
Sorry I do not understand at all. You have just suggested changing the proposal from default= to annotated= but the same objection applies. You can't annotate nothing, and there always has to be a default as it may be that none of the annotations are understood by a particular system.
So as before
<semantics annotated='none'>
<annotation-xml>data</annotation-xml>
<annotation-xml>data</annotation-xml>
<!-- also, there is no default -->
</semantics>
is just
<semantics>
<mrow/>
<annotation-xml>data</annotation-xml>
<annotation-xml>data</annotation-xml>
<!-- also, there is no default -->
</semantics>
so why introduce new syntax?
In the internationalization examples, there is no intended annotated, default expression. There is, instead, a set of alternatives of type “alternate-representation”.
<math id="eq1">
<semantics>
<annotation-xml lang="en" encoding="application/mathml-presentation+xml">...</annotation-xml>
<annotation-xml lang="fr" encoding="application/mathml-presentation+xml">...</annotation-xml>
<annotation-xml lang="es" encoding="application/mathml-presentation+xml">...</annotation-xml>
<annotation-xml lang="de" encoding="application/mathml-presentation+xml">...</annotation-xml>
<annotation-xml lang="ja" encoding="application/mathml-presentation+xml">...</annotation-xml>
</semantics>
</math>
The <annotation>
and <annotation-xml>
elements aren’t intended to annotate an expression; they’re intended to indicate alternatives for presentation, semantics, metadata or other content, depending upon which annotation keys adorn the <annotation>
and <annotation-xml>
elements. A toggle could be of use on the <semantics>
element to have the expressiveness for both usages of the same elements: <semantics>
, <annotation>
, <annotation-xml>
.
Throughout this issue, content selection algorithms have been indicated. Together with the encoding
attribute, lang
, notation
, media
, and q
attributes can facilitate content selection from alternatives in a manner which resembles HTTP-based content negotiation for mathematical content.
Towards concrete examples, let us consider a JavaScript function:
/* example content selection algorithm */
function sortAlternatives(alternatives, acceptLanguage, accept) { … }
With an example usage:
var alts = document.getElementById('eq1').getAnnotationElementsByKey('https://www.openmath.org/', 'mathmlkeys', 'alternate-representation');
alts = sortAlternatives(alts, 'en; q=1.0, fr; q=0.8, es; q=0.8, de; q=0.8, ja; q=0.8', 'application/mathml-presentation+xml; q=1.0, application/xhtml+xml; q=0.8, application/svg+xml; q=0.8, image/png; q=0.2, image/*; q=0.2, */*; q=0.1');
With the input equation being:
<math id="eq1">
<semantics>
<annotation-xml encoding="application/xhtml+xml">...</annotation-xml>
<annotation-xml encoding="application/svg+xml">...</annotation-xml>
<annotation-xml encoding="application/mathml-presentation+xml">...</annotation-xml>
</semantics>
</math>
the indicated function, for the indicated input parameters, should return a sequence, array or collection with a first item being an <annotation-xml>
element with its encoding
attribute set to “application/mathml-presentation+xml”.
Of interest are uses of <semantics>
, <annotation>
and <annotation-xml>
elements to convey sets of alternatives without annotating first child expressions. It is possible that a toggle could be of use on <semantics>
elements to have the expressiveness for both usages.
Under consideration are syntaxes:
<math id="eq1">
<semantics>
<mrow />
<annotation-xml lang="en" encoding="application/mathml-presentation+xml">...</annotation-xml>
<annotation-xml lang="fr" encoding="application/mathml-presentation+xml">...</annotation-xml>
<annotation-xml lang="es" encoding="application/mathml-presentation+xml">...</annotation-xml>
<annotation-xml lang="de" encoding="application/mathml-presentation+xml">...</annotation-xml>
<annotation-xml lang="ja" encoding="application/mathml-presentation+xml">...</annotation-xml>
</semantics>
</math>
and:
<math id="eq1">
<semantics toggle="toggled">
<annotation-xml lang="en" encoding="application/mathml-presentation+xml">...</annotation-xml>
<annotation-xml lang="fr" encoding="application/mathml-presentation+xml">...</annotation-xml>
<annotation-xml lang="es" encoding="application/mathml-presentation+xml">...</annotation-xml>
<annotation-xml lang="de" encoding="application/mathml-presentation+xml">...</annotation-xml>
<annotation-xml lang="ja" encoding="application/mathml-presentation+xml">...</annotation-xml>
</semantics>
</math>
There doesn’t always have to be a default as, in the event that none of the provided annotations are understood by a system, iterated in a sequence determined by a content selection algorithm, the system can provide a visual indicator to users in a manner resembling a picture that didn’t load.
there always has to be a default, for example in the language switch version perhaps the current system locale is none of the specified languages. As there is no default specified in the markup, the mathml spec would have to specify the default rendering in this case, presumably it would be like an empty mrow, which is why I say the suggested markup is the same as not having the attribute and a first child of <mrow/>
.
A downside of the <mrow/>
syntax:
<math id="eq1">
<semantics>
<mrow />
<annotation-xml lang="en" encoding="application/mathml-presentation+xml">...</annotation-xml>
<annotation-xml lang="fr" encoding="application/mathml-presentation+xml">...</annotation-xml>
<annotation-xml lang="es" encoding="application/mathml-presentation+xml">...</annotation-xml>
<annotation-xml lang="de" encoding="application/mathml-presentation+xml">...</annotation-xml>
<annotation-xml lang="ja" encoding="application/mathml-presentation+xml">...</annotation-xml>
</semantics>
</math>
is that, while it provides a default, it seems to also be stating that the first child element is an empty mathematical expression and that the provided alternatives are annotating it.
Instead, we could toggle the interpretation and functionality of the interrelated <semantics>
, <annotation>
and <annotation-xml>
elements so that the markup indicates a set of alternatives for presentation, semantics, metadata, and so forth.
<math id="eq1">
<semantics toggle="toggled">
<annotation-xml lang="en" encoding="application/mathml-presentation+xml">...</annotation-xml>
<annotation-xml lang="fr" encoding="application/mathml-presentation+xml">...</annotation-xml>
<annotation-xml lang="es" encoding="application/mathml-presentation+xml">...</annotation-xml>
<annotation-xml lang="de" encoding="application/mathml-presentation+xml">...</annotation-xml>
<annotation-xml lang="ja" encoding="application/mathml-presentation+xml">...</annotation-xml>
</semantics>
</math>
A standard default, like the icons for missing pictures in browsers, would be useful to specify. A standard default would allow users to recognize when the default is visible to them and to communicate occurrences to website administrators or software developers. We can envision standard default icons resembling the icons for missing pictures but with a capital sigma symbol or other math symbols atop it.
On the topic of internationalization, should an author desire to provide a language-invariant fallback, they could provide one or more alternatives with an omitted lang
attribute.
<math id="eq1">
<semantics toggle="toggled">
<annotation-xml lang="en" encoding="application/mathml-presentation+xml">...</annotation-xml>
<annotation-xml lang="fr" encoding="application/mathml-presentation+xml">...</annotation-xml>
<annotation-xml lang="es" encoding="application/mathml-presentation+xml">...</annotation-xml>
<annotation-xml lang="de" encoding="application/mathml-presentation+xml">...</annotation-xml>
<annotation-xml lang="ja" encoding="application/mathml-presentation+xml">...</annotation-xml>
<annotation-xml encoding="application/mathml-presentation+xml">...</annotation-xml>
</semantics>
</math>
We are not adding elements to Content MathML in this round (see the current working group Charter) this effectively also precludes making structural changes to <semantics>
so I have retagged this as MathML-Next for possible consideration for a future version.
[minor admin] In the MathML Full WG meeting on Sep 28th, 2023, we agreed to re-title issues scheduled for the next charter with "MathML-Next", to avoid confusion.
Introduction
Some ideas for MathML4 are presented. Comments and discussion are welcomed.
Presentation, Semantics, Metadata and Extensibility
Presentation and Semantics
Metadata
Extensibility
Are there any other varieties of content for a mathematical expression beyond “presentation”, “semantics” and “metadata”? Might we want to include “other” for extensibility?
Would content which interrelates mathematical expressions, e.g. for mathematical proofs, be expression “metadata” or “other” content? Would derivations of mathematical expressions be expression “metadata” or “other” content?
Selecting Content from Alternatives and Content Negotiation
Algorithms for selecting “presentation”, “semantic”, “metadata” or “other” content from alternatives may resemble agent-driven or reactive content negotiation.
Together with the
encoding
attribute,lang
,notation
,media
, andq
attributes can facilitate content selection from alternatives in a manner which resembles HTTP-based content negotiation for mathematical content.See also: MathML3
<annotation>
element See also: MathML3<annotation-xml>
element See also: HTML5<source>
elementInternationalization
For scenarios where natural language is utilized in the “presentation” annotation content, a BCP47 language attribute can adorn annotation markup and “presentation” annotations can also be described in expression “metadata”.
Multimodality
“Presentation” annotations can include content spanning multiple modalities, e.g. SSML or audio, and “presentation” annotations can also be described in expression “metadata”.
Notation
Might the values of a
notation
attribute be the display names of notations, URI’s, or encoded strings resembling BCP47? Might the values of anotation
attribute be, instead, lists of settings and their values resembling thestyle
attribute?The following example shows a combination of multiple presentation formats with multiple notations.
Media Queries
A
media
attribute can facilitate the use of media queries. “Presentation” annotations can also be described in expression “metadata”.Quality Scores
Remote Content
Remote Resources
Remote Components
Perhaps utilizing HTTP-based agent-driven or reactive content negotiation, URL’s could be provided for “presentation”, “semantics” and “metadata” components.
Alternatively, via a “partial” keyword or Boolean attribute, multiple MathML files could be merged together into mathematical expressions.
URL String Interpolation, Templating and Formatting
Described are uses of a
pattern
attribute for providing string templates with which string interpolation algorithms can produce values forsrc
attributes on<annotation>
and<annotation-xml>
elements.A
pattern
attribute could be of use for specifying string interpolation placeholders in URL query strings.A
pattern
attribute could also be of use for specifying string interpolation placeholders in file names and paths.Media queries could be utilized via a
media
attribute.Those
<annotation-xml>
and<annotation>
elements withencoding
,lang
,notation
,media
, orq
attributes could be described as “more specific” and thus to be utilized first when matching for content selection.The
encoding
attribute, thelang
attribute and possibly thenotation
attribute could be utilized with multiple, delimited (e.g. space delimited) values for specifying when a pattern is valid.There is a caveat to delimiting MIME types with spaces in that MIME types can have parameters and spaces could exist between MIME types and their parameters as well as in the quoted string values of their parameters, for instance when specifying codecs.
See: RFC 7231 § 3.1.1.1, RFC 6381
MIME types with spaces can be observed in the HTML5 specification, e.g. HTML5
<source>
element § Example 18.If spaces are desired to delimit sets or lists of MIME types, then collapsing spaces in MIME types, including those with complex parameter values, e.g. codecs, would be required.
A fuller set of placeholders can be created for URL string interpolation. For example, a customizable filename
{extension}
placeholder can be derived from the encoding selected.See also:
printf
format string See also: String interpolation See also: Template processingRemote Mathematical Expressions
Remote mathematical expressions could be facilitated via a
src
attribute on<math>
elements.Additionally, HTML5
<img>
and<object>
elements could be of use.See also: HTML5
<img>
element See also: HTML5<object>
element