Does the restriction on Deprecated MathML cause retroactive content breakage?

[bduga]

In the section on MathML restrictions

EPUB Creators MUST NOT include elements and attributes marked as deprecated in [MATHML3] within MathML markup in XHTML Content Documents.

Does this mean, in this era of living standards, that as MathML adds items to the deprecated list existing EPUB content is retroactively made non-conforming?

[iherman]

To be precise: MathML 3 is not a "living standard". The charter of the Math WG talks about MathML 4, and also about a Core level 1 which would codify, as far as I understand, what is really to be implemented in browsers. I.e., formally, we do not have a problem.

However, I believe the outcome of what the current MathML WG does, and its possible influence on the way MathML is adopted in the browser world, will force us to revisit the way we refer to MathML In a future version of EPUB 3. We may have to refer to the upcoming Core instead of MathML 3, or maybe to MathML 4 instead of 3... I do not know.

I think the current statement is fine and the only thing we can normatively do, but we may want to add some additional note, referring to MathML Core (note that the editor's draft is way more up-to-date than the formal draft, that WG does not seem to follow the immediate publishing approach that we have). I.e., we may want to say that EPUB Content authors should to restrict to the element an attribute set defined by that (evolving) draft to avoid future problems.

It would be great if some interested parties in the EPUB community were present in the Math WG, b.t.w. We are one of the main consumer communities of MathML after all...

[mattgarrish]

To the question of ever-evolving standards, there's always a risk that content that is valid now becomes invalid in the future.

We caution about this for HTML and SVG in the "relationship" section. For example, see: https://w3c.github.io/epub-specs/epub33/core/#caution-0

Maybe we should have a similar section for MathML, although speculating too much about the future never works out well.

[iherman]

The problem is: in theory, the same applies for all the standards we refer to. It may happen to SMIL (although the probability is low), to CSS, and MathML, JavaScript...

Maybe a generic 'caution' box would be better somewhere in the standard, instead of referencing to a specific one.

[mattgarrish]

Probably right at the start of the relationship to other specifications would do since this is a pan-EPUB issue.

Taking the HTML note as a basis, perhaps we could add something like:

CAUTION

The technologies EPUB 3 builds on are constantly evolving. Some, typically referred to as "living" or "evergreen" standards, are subject to change daily, while others may only be updated to their latest versions when EPUB undergoes a new revision. In all cases, it is possible that previously valid features may become obsolete or be removed from these technologies. In general, however, the removal of features normally only occurs when serious issues arise with them (e.g., due to a lack of support or because of security issues). Regardless, EPUB Creators should be cautious about using any feature of a technology that is not yet widely supported and monitor the ongoing development of these technologies for changes that could impact the validity of their EPUB Publications.

[iherman]

Note, however, that https://w3c.github.io/epub-specs/epub33/core/#sec-intro-relations does not include subsection on MathML...

[bduga]

My concern was not the general one of backwards incompatible changes in other standards, but rather that we added a constraint in our spec that limits the ability of MathML to make backwards compatible changes. Specifically, if MathML adds anything to the list of deprecated elements, this will retroactively cause all EPUBs that use some perfectly compliant MathML to suddenly break, even though the MathML remains legal. Though as Ivan points out, this isn't a living standard, so if we are cautious moving forward and review MathML for newly deprecated elements every time we update the reference, we should be fine. That said, I have no idea if anyone does that. At the very least, we should add some sort of process step to require such a review.

[mattgarrish]

Note ... that ... does not include subsection on MathML

No, but I'm fine with adding one, if that's what you're asking. The relationships are supposed to call out unique circumstances, not just be a reference list, but in MathML's case we should probably note how we only support presentation markup.

I'm just wary about making any statements too specific about how MathML might change for a version we wouldn't automatically support.

[clapierre]

I am part of the accessibility TF of the MathML Refresh WG and can bring up our concerns with them and have them comment in this thread if that will help.

[davidcarlisle]

MathML3 (as a standard) isn't "living" in the sense of current HTML specification for example, so the text of the standard won't change.

That said, MathML4 (and perhaps more relevant, MathML Core) are in draft and if implementations move on to implement those, a document conforming to MathML3 might not work on future implementations.

I would guess that at least some epub implementations will be relying on browser support and there the situation looks like it will be improving. MathML-Core basically standardises that subset of Presentation MathML that was (and will be) implemented in web browsers, together with specification of the layout in terms of the CSS box model, in a style more like other web platform specifications for HTML or SVG.

MathML4 (which unlike MathML-Core is still at early draft stage and not yet submitted as a Working draft at W3C) is being re-factored as an extension of MathML Core, essentially puttting back everything that was in MathML3 (the decision about what to do about things that were deprecated a MathML3 is still open) In the current draft of the schema at https://w3c.github.io/mathml/#parsing_rnc_legacy we have things that were deprecated marked as invalid in the mathml4 schema, with an additional "legacy" schema that makes them valid for applications that need that, but this is early stage yet, we could change that especially if we had requirements specified from here or elsewhere.

Just looking a MathML Core, the elements missing are mfenced, and the elements for "elementary layouts" mstack mlongdiv etc, plus several attributes for "fine tuning" the spacing. (none of these elements are implemented in the current firefox mathml rendering for example, so no documents relying on that will miss them not being in MathML Core).

In view of the comment above about only supporting Presentation MathML, hopefully at some point you will be able to say you support MathML Core as a full spec rather than a slightly undefined Presentation MathML subset of the large MathML spec. Well that's the intention why we are refactoring the spec that way, so hopefully desktop browser implementations will be able to support MathML Core in full and in an interoperable way.

MathML 4 https://w3c.github.io/mathml/

MathML Core https://w3c.github.io/mathml-core/

[mattgarrish]

In the current draft of the schema at https://w3c.github.io/mathml/#parsing_rnc_legacy we have things that were deprecated marked as invalid in the mathml4 schema, with an additional "legacy" schema that makes them valid for applications that need that

I think this may be central to why we have the statement about not allowing deprecated features. I don't see in the MathML3 schemas that the features would be flagged as invalid, so maybe the statement was added as part of ensuring only a subset of markup is valid for epubcheck verification.

Putting the deprecated display attribute on a math element doesn't trigger any errors in epubcheck, though, and skimming the schemas I can't a schematron file that enforces no deprecated elements or attributes, so it looks like this rule was never implemented.

So we could arguably drop the requirement. I don't know if it practically solve anything for us.

[mattgarrish]

Putting the deprecated display attribute

Helps to use the right deprecated attribute... :(

mode is flagged, so I must have missed where this is implemented.

[NSoiffer]

Adding on to what @davidcarlisle wrote: MathML core is a starting point for what is supported by browsers. There are already some suggestions for what might go into a level 2, but that discussion is very preliminary.

For those features in full but not in core, there are "polyfills"/transforms so one can get the benefits of a browser implementation for the vast majority of the MathML and get fallback to the JS transforms for anything else.

Core is focused on what can be implemented in browsers "easily". Although it tries to catch the basics of MathML, there are some features of MathML that didn't make it in for various reason (mfenced being one of them). On the other hand, MathML Full tends to only deprecate things that are confusing, poorly spec'd, or never implemented (e.g, setting the value of a maththinspace). Hence, I think the concern about incompatible changes in MathML full is probably mostly a theoretical one and doesn't differ from reliance on other specs as @mattgarrish already said.

[bduga]

Hence, I think the concern about incompatible changes in MathML full is probably mostly a theoretical one and doesn't differ from reliance on other specs as @mattgarrish already said.

My concern is not over incompatible changes in MathML, it is about backwards compatible changes in MathML that cause an EPUB to break. This is different from other specs, because we do not add an additional requirement to disallow deprecated features in any of those specs. So if CSS decides to deprecate the display property, EPUBs that have stylesheets that use display remain perfectly legal, since the CSS remains legal. However, if MathML decides to deprecate msup, then every existing EPUB that has msup will suddenly start to fail EPUBCheck. As others have noted, we do seem to have a versioned reference to MathML, so as long as we never change the reference or if nothing is ever deprecated in MathML we are fine.

[mattgarrish]

However, if MathML decides to deprecate msup, then every existing EPUB that has msup will suddenly start to fail EPUBCheck.

Whenever HTML adds new elements/attributes to the obsolete and non-conforming list, you get the same result. HTML can just spring it on us anytime while we have to wait for a revision to see if changing our reference to MathML will break anything.

(And, yes, we did review our dated spec references in the past for incompatibilities when we updated them, but most things that are dated now aren't under development anymore.)

That said, I still think the requirement is a bit of a failed experiment. It was supposed to be part of making MathML rendering a little simpler to implement, but I doubt our spec has moved the needle any in that regard. It's not like anyone is making MathML rendering exclusively for EPUB's situation.

[iherman]

That said, I still think the requirement is a bit of a failed experiment. It was supposed to be part of making MathML rendering a little simpler to implement, but I doubt our spec has moved the needle any in that regard. It's not like anyone is making MathML rendering exclusively for EPUB's situation.

I am not sure if I understand what you think we should do. Remove that statement referred to in the issue and add the generic caution clause for all external standard references? I would be o.k. with it if that is what you say...

[mattgarrish]

I am not sure if I understand what you think we should do. Remove that statement referred to in the issue and add the generic caution clause for all external standard references?

Right, having a general caution that specs change in incompatible ways is fine, but I don't think we need to explicitly ban features of MathML that aren't banned by that specification.

[iherman]

The issue was discussed in a meeting on 2022-03-31

List of resolutions:

• Resolution No. 2: merge PR 2137, close issue 2118.

View the transcript

### 2. Remove restriction on mathml deprecated features (pr epub-specs#2137) _See github pull request [epub-specs#2137](https://github.com/w3c/epub-specs/pull/2137)._ _See github issue [epub-specs#2118](https://github.com/w3c/epub-specs/issues/2118)._ **Matt Garrish:** duga had opened this initially, and we went back and forth. … i think his concern is that we're imposing a restriction on MathML's deprecated features that MathML itself doesn't impose on its features. … they are deprecated, but you're still allowed to have them in MathML. … we are imposing on their spec. … he's asked that we not restrict these deprecated features. … I agree, and I don't think us putting a ban on MathML features moves the needle on MathML rendering. … math rendering is made for web browsers, and we just use what they do. … if getting rid of these restrictions smooths over a spec weirdness, that is fine. … people don't hand write MathML anyway. … so this PR takes out the MUST NOT that was there before. **Dave Cramer:** this is in keeping with changes we've been making incrementally over the last 5-10 years. … initially we were intervening with the goal of making it easier for people who were trying to write RS from scratch. … to allow them to skip support for complicated features. … this PR is in keeping with our take on epub as a container for these other technologies. … we leave it up to these other specs. **Matt Garrish:** I don't think these restrictions work anymore, but they were important at the time. **Dave Cramer:** so I would propose we merge this. > *Murata Makoto:* +1. > **Proposed resolution: merge PR 2137, close 2118.** *(Dave Cramer)* > *Dave Cramer:* +1. > *Shinya Takami (高見真也):* +1. > *Masakazu Kitahara:* +1. > *Matt Garrish:* +1. > *Toshiaki Koike:* +1. > *Matthew Chan:* +1. > ***Resolution #2: merge PR 2137, close issue 2118.***