Skip to content

Distinguishing fragments and documents in <annotation>/<annotation-xml> #232

Open
@Jamesernator

Description

@Jamesernator

When processing <annotation>/<annotation-xml> elements it is unclear whether a particular annotation represents a document fragment or an entire document.

For example consider the following annotation:

<!doctype html>

<div id="some-math">
  <math xmlns="http://www.w3.org/1998/Math/MathML">
    <semantics>
      <mi>x</mi>
      <annotation-xml encoding="application/xhtml+xml">
        <html xmlns="http://www.w3.org/1999/xhtml">
          <body>
            <i>x</i>
          </body>
        </html>
      </annotation-xml>
    </semantics>
  </math>
</div>

In this annotation we have an entire document, but this means that this rendering is not suitable for replacement inline. But compare this with the following annotation:

<annotation-xml encoding="application/xhtml+xml">
  <i xmlns="http://www.w3.org/1999/xhtml">x</i>
</annotation-xml>

This annotation is only a document fragment and so logically would be valid for placement inline.

This is problematic because processing an entire document might mean different behaviour, for example it's not clear what should be placed inline (e.g. simply taking the content of <body> might not be appropriate if <head> contains things, so does this mean it needs to be put in an iframe?).

This doesn't just apply to HTML either, it applies to any document type where <math> can be embedded. This includes <math> itself.

For example are the following two annotations equivalent? The spec makes this unclear:

<annotation-xml encoding="MathML-Content">
  <math xmlns="http://www.w3.org/1998/Math/MathML">
    <apply xmlns="http://www.w3.org/1998/Math/MathML"">
      <plus/>
      <ci>x</ci>
      <ci>y</ci>
    </apply>
  </math>
</annotation-xml>
<annotation-xml encoding="MathML-Content">
  <apply xmlns="http://www.w3.org/1998/Math/MathML">
    <plus/>
    <ci>x</ci>
    <ci>y</ci>
  </apply>
</annotation-xml>

When combined with src="...", a processor (such as the one I'm writing to process content mathml trees and generate presentation mathml) may unncessarily need to fetch documents in order to determine which one is the inline version vs the complete document. And even then it's unclear which should be used.


Proposal: I'd like to propose the addition of a single boolean attribute, document. When this attribute is present, it acts as a hint to any processor that procesess mathml that the annotation points to an entire other document rather than simply a fragment.


Additional Clarification needed: While the proposed document attribute resolves the issue for some processing. It's still unclear for <annotation-xml encoding="MathML-{Presentation,Content}"> whether or not it can point to an entire document.

While all examples of encoding="MathML-Content" in the spec are fragments, it would be unfortunate not to be able to do the nice use case of pointing to other documents as references. But it's unclear if this is allowed as simply replacing the <semantics> with the given document would lead to a <math> element being a descedant of another <math> element (which is not allowed).

e.g. Pointing to other documents within a <annotation-xml> like so for their definitions would be useful:

<math xmlns="http://www.w3.org/1998/Math/MathML">
  <semantics>
    <mi>E</mi><mo>=</mo><mi>m</mi><msup><mi>c</mi><mn>2</mn></msup>
    <annotation-xml
      document
      encoding="Content-MathML"
      name="contentequiv"
      src="./energy-mass-equivalence.mml"
    ></annotation-xml>
  </semantics>
</math>
<!-- energy-mass-equivalence.mml -->
<math xmlns="http://www.w3.org/1998/Math/MathML">
  <apply>
    <eq/>
    <csymbol cd="SI_DerivedQuantities1">energy</csymbol>
    <apply>
      <times/>
      <csymbol cd="SI_BaseQuantities">mass</csymbol>
      <apply>
        <power/>
        <csymbol cd="FundamentalPhysicalConstants1">speed-of-light</csymbol>
        <cn>2</cn>
      </apply>
    </apply>
  </apply>
</math>

Metadata

Metadata

Assignees

No one assigned

    Labels

    MathML-NextIdeas for future releases

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions