Decide what to do with Content MathML

[fred-wang]

Just opening this for the record.

Currently it's in chapter 4 of the full spec: https://mathml-refresh.github.io/mathml/chapter4.html
There is not any plan to implement it in browsers and a fortiori it should not be in the MathML Core spec.

Should we keep it in the full spec? Or move it into a separate document?

cc @mrego @kohlhase

[davidcarlisle]

Agreed it's something we should discuss but I'd strongly favour keeping it in the full spec. I don't think not being in core should be a strong indication that something be removed from the full spec, otherwise full and core end up being the same.

that said, if it is in, we should make it explicit that it's not in core and on the web some client side mapping to core presentation elements will be needed. (That is likely to be true of parts of presentation mathml as well)

[fred-wang]

I think this is a topic that comes often, it was raised again at the latest CSS WG F2F meeting. Personally, I think not having it in Core spec should be enough to address people's concerns. However, I think it is still open how we organize the full spec and profiles. Content MathML seems quite relatively independent so it could be in its own document if that makes things easier to manage.

[dani31415]

A semantic layer is needed in order to disambiguate the meaning of the formulas in presentation MathML. This is used in accessibility but also equation editors benefit from it. For example, at WIRIS we found some formulas created by a legacy tool that rely on the piecewise content-MathML element to express piecewise functions.

I'm not saying that this semantics have to necessarily be done with content MathML neither that we should remove it. My suggestion is to extend presentation MathML with a new set of attributes that help define the semantics. I will not go into further detail here. But what is important is that this should be done with the collaboration of the Aria WG.

[AdamSobieski]

I agree with @fred-wang that Content MathML should be its own document.

In my opinion, there should be at least three specs: MathML4, MathML4 Presentation, and MathML4 Content.

[NSoiffer]

A problem with moving Content MathML into its own document is that there is also Chapter 5: Mixing Presentation and Content Markup. Perhaps a little rewriting of that would make it seem like it belongs in a separate Content MathML document. At the moment, it is written from the perspective that both are co-equal and hence, belongs either in both documents or itself is a separate document describing how to marry the two types of MathML.

[davidcarlisle]

I'd still strongly argue against making separate document for Content, for multiple reasons

Mainly that the mathml4 spec has 7 chapters and 9 appendices and apart from chapters 3 and 4 both apply to presentation and content. You would need to put most of that in to the "content" specification leaving a separate document for "presentation but not in core" that would be hard to make a coherent self standing document.

Also the rec track process implies a non trivial overhead, in editorial time, and time for W3C membership ballots etc. You can only edit the specifications if you know the whole specification is moving together as a coherent work. If you submit different parts to the ballot process as separate documents you have to be able to handle the possibilities of them progressing at different rates or not progressing at all.

There are clear advantages to splitting out core to target web browser/ CSS based implementations, and in that case that over-rides the downsides in the cost of splitting the spec, but I see only costs and no advantages in further fragmenting the main mathml specification.

[AdamSobieski]

@davidcarlisle , is "MathML4 Core" what I referred to as "MathML4 Presentation"?

[fred-wang]

@davidcarlisle , is "MathML4 Core" what I referred to as "MathML4 Presentation"?

@AdamSobieski No, it's the subset of "MathML4 Presentation" described in https://mathml-refresh.github.io/mathml-core/

[Jamesernator]

In another thread I voiced my opinion that browsers shouldn't implement MathML core: #100 (comment)

However since then my feelings have flipped around, instead I think it would be good for MathML to actually define presentation (which could be done via a shadow DOM of presentation elements).

For cases where presentation could have multiple alternatives e.g. multiplication with a × b, a ⋅ b MathML could define css properties for a decent number of common presentations e.g. math-multiplication-style: dot; / math-multiplication-style: juxaposition;. For other cases an escape hatch could be provided via custom elements (pending a couple proposals):

<interval is="from-to-interval" closure="open">
  <ci>x</ci><cn>1</cn>
</interval>

import onChildrenChanged from '/path/to/onChildrenChanged.js';

class FromToInterval extends MathIntervalElement {
  #shadowRoot = this.attachShadow({ mode: 'closed', slotting: 'manual' });

  constructor() {
    this.shadowRoot.innerHTML = `
      from
      <slot name="from"></slot>
      to
      <slot name="to"></slot>
    `;

    const fromSlot = this.shadowRoot.querySelector('slot[name="from"]');
    const toSlot = this.shadowRoot.querySelector('slot[name="to"]');

    onChildrenChanged(this, () => {
      if (this.children[0]) {
        fromSlot.assign(this.children[0]);
      }
      if (this.children[1]) {
        toSlot.assign(this.children[1]);
      }
    });
  }
}

customElements.define('from-to-interval', FromToInterval, {
  namespace: 'http://www.w3.org/1998/Math/MathML',
});

[physikerwelt]

I'd still strongly argue against making separate document for Content, for multiple reasons

Mainly that the mathml4 spec has 7 chapters and 9 appendices and apart from chapters 3 and 4 both apply to presentation and content. You would need to put most of that in to the "content" specification leaving a separate document for "presentation but not in core" that would be hard to make a coherent self standing document.

Also the rec track process implies a non trivial overhead, in editorial time, and time for W3C membership ballots etc. You can only edit the specifications if you know the whole specification is moving together as a coherent work. If you submit different parts to the ballot process as separate documents you have to be able to handle the possibilities of them progressing at different rates or not progressing at all.

There are clear advantages to splitting out core to target web browser/ CSS based implementations, and in that case that over-rides the downsides in the cost of splitting the spec, but I see only costs and no advantages in further fragmenting the main mathml specification.

I second that.

[dginev]

Is there any chance that we can close this issue as resolved? MathML Core is now fleshed out, and we have frozen changes to Content MathML for the duration of MathML 4.

There may be more of a focus placed on the Content chapter in MathML 5, but that ought to be its own issue(s).

[NSoiffer]

It has the MathML-Next label (i.e., something for MathML 5), so it seem appropriate to leave it open.

[physikerwelt]

I propose to discuss that in the next intent meeting. While I understand that content MathML and intent are not identical, I think there is some alignment between both concepts, that is not yet adequately described by the spec.

[NSoiffer]

I really want to move on to the details of what is in core and what isn't in core at the next few meetings.

Perhaps this can be a topic for our TPAC meeting on 14 Sept.

[physikerwelt]

Perhaps this can be a topic for our TPAC meeting on 14 Sept.

Unfortunately, I didn't make it. I would appreciate it if someone could share some updates here.

[dginev]

It has the MathML-Next label (i.e., something for MathML 5), so it seem appropriate to leave it open.

@NSoiffer having that label is clearly not preventing active discussions during the MathML 4 charter, but I fear that the context of this issue will prevent the discussions to be constructive.

The original question was posed Feb 2019 and had the MathML 4 label. The "needs resolution" label was removed August 2020, and then the MathML 4 label was removed June 2022. In my eyes this makes the issue close-able.

Whether there is a slight refresh or a major refresh to Content MathML in the 5th version of the spec, that warrants its own issue(s), detached from the considerations here - which are really resolved by the decision to "freeze as-is" the Content chapter for MathML 4, and the observation that MathML Core does not need to be concerned with Content MathML. The original question has been answered.

Discussing the relationship of the "intent" attribute and Content MathML is a great example for something that can be in a new standalone issue (for the current MathML 4)

[physikerwelt]

I agree with @dginev, and I think it is important to review intent with regard to the frozen content MathML standard for self-consistency.

[NSoiffer]

The current plan (which may change tomorrow...) is to discuss this and the status of some other issues at the meeting on Thursday. Hopefully you (@physikerwelt) can make it to that meeting.

[NSoiffer]

We will discuss on 28, Sept meeting

[dginev]

We had a discussion of the recently raised points here during our MathML Full WG meeting today (Sep 28th, 2023).

We agreed to close this issue as resolved in its original scope, by virtue of Content MathML remaining "frozen" in MathML 4, as per the group's charter. The group had broad agreement that a larger conversation around Content MathML will be appropriate after the current charter is completed.

We also agreed that a new discussion on clarifying the relationship between MathML Intent and Content MathML is appropriate for the current MathML 4 effort. That will benefit from its own separate issue.