Re: WG draft charter

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
> <mailto: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