Re: WG draft charter

Hi Frédéric,

Very curious to read about the lessons learned and trying to ensure
MathML's browser support remains for the long-haul "by design". I
think there is a lot of wisdom in your perspective.

I wanted to ask for your thoughts on the "content side" of the MathML
spec. Do you think it should even attempt to aim to one day be in
Core, or do you think it is completely irrelevant until there are
compelling browser applications that consume the content markup?

I am trying to get a workable perspective on where this "multi-level"
approach to MathML will guide us to, and I mentioned in another thread
that the accessibility mini spec we're attempting looks to be a lot
closer to practical browser applications than cMML ever was. Do you
find it reasonable for us to work on small application-oriented
"content subsets", and then aim to elevate them to the browser-level
of rigor/testing/support? And how should we minimize being
controversial while doing so?

Thanks for your thoughts,
Deyan

On Mon, Aug 3, 2020 at 7:03 AM Frédéric Wang <fwang@igalia.com> wrote:
>
> Maybe I haven't read in details but I don't think these address my concern. At least MathML3 also had similar W3C's "two interoperable implementations" and "test suite" rules, and that unfortunately didn't prevent it from becoming what it is. I'd prefer to follow a stricter model like WHATWG and the browser community do, where you need support and test coverage for each change.
>
> What you quoted is "deliverables" and "success criteria" which just sounds goals not decision policy, so I don't see how it prevents us from putting something in core that has no implementor's interest or is controversial in the browser community or no test plan. Actually, one could say this is worse, since that means we can actually put a complex/controversial feature, wait for the PR application, finally try to convince browser, get pushback and then give it up with the idea. Moreover, browser vendors really only use working drafts as a reference these days, so I don't think MathML Core drafts should even contain controversial things.
>
> Note that my remark is only for MathML Core, I don't care if people put things in MathML full that have no browser implementor interest if this is just to present something for discussion or to experiment with polyfills. What I don't want is the way of thinking "put something in core without following the modern approach of the browser community, with the hope that it will get natively implemented in browsers".
>
> On 03/08/2020 01:52, Neil Soiffer wrote:
>
> I think what you want is at least partially addressed by what is written in "deliverables" for MathML Core Level 1:
>>
>> This specification provides an initial integration to the platform with increased implementation details, focused on a subset of MathML 3 which had wide implementation and could be 'fit' into the platform. It greatly details and relies on automated web platform tests aiming to greatly improve MathML interoperability.
>
>
> It is supported by the listing of a Test Suite and Implementation report in the non-normative documents. This is backed up by the success criteria:
>>
>> There are multiple, independent, interoperable native implementations of MathML Core Level 1 that are widely used
>
>
> Furthermore, we can't proceed to Proposed Recommendation (PR) without two interoperable implementations as per W3C policies. So no matter how important I think linebreaking support may be and how good I might be at convincing others that it is essential for Core, without the implementations, Core will never make it to PR without it being implemented.
>
> Based on other group's "Decision Policy" sections, that section should concern itself with voting policies (consensus, voting time periods, ...), not criteria on which way a vote should go.
>
> We need to improve the intro language, the scope language, and language about what the group produces. I think changes there will be able to address your concerns. I hope you and others will suggest wording changes/improvements to those sections as we move forward with the charter development.
>
>    Neil
>
>
>
> On Fri, Jul 31, 2020 at 3:15 PM Frédéric Wang <fwang@igalia.com> wrote:
>>
>> Thanks Brian for working on the draft,
>>
>> I just skimmed through it, I think it looks good overall. My main
>> concern is about the policy regarding what will go into MathML Core
>> specifications (or any other one that is intended to be implemented
>> natively in browsers).
>>
>> I believe the charter should really contain strong rules that aligns
>> with the policy of other web platform standards (maybe in "Decision
>> policy"?), so we are sure that we don't end up adding/keeping something
>> in the spec that, for example, lacks rigorous implementation details,
>> does not have web platform tests, is controversial among the browser
>> community or for which nobody is committing to implement it.
>>
>> We have tried our best to adhere to these principles and that was
>> instrumental in order to convince the browser community that our CG is
>> credible and address criticisms of the MathML3 specification. However,
>> this is a topic that has been raised again and again in Core meetings.
>> So I think we should make sure that this is clearly stated in the charter.
>>
>> --
>> Frédéric Wang
>>
>>
>
> --
> Frédéric Wang

Received on Monday, 3 August 2020 17:34:41 UTC