Re: Charter changes/resolutions -- last call

Dear Fred and All,

It's certain that 'MathML Core must follow the
minimal requirements for a "good" web platform
specification', as done in other groups where browser
vendors are involved. Actually, it might be helpful
if the CG could see examples of relevant group
charters and decision procedures they adopted. So
could you point to such, please?

It wouldn't be a good idea "to go back to a
low-quality standard", as you suggest is a danger.
Even for a MathML 4 your warnings are surely
relevant.

W3C requirements may not be the sticking point.
It seems that since about May 2019 the HTML and
DOM standards are largely the purview of the
WHATWG, along with other key standards, as outlined
at https://spec.whatwg.org .
[https://www.w3.org/blog/news/archives/7753]

As an exercise in understanding the sense of the
requirements that Brian was trying patiently to
explain, I constructed the following paragraph.
I based it on the example he was good enough to
provide a link to. The formulation seemed to me
a pretty extreme, if satisfyingly explicit, straw-man:
"""
It is the intent in producing the simplified Core
version of MathML to set out a collection of MathML
features that can be, at a minimum, implemented in
the dominant browsers of today's Web Platform.
Therefore it is a requirement of Core's preparation
that it be made as a document under Git, and that all
feature changes be carried out through Git Pull
Requests.  The Requests shall be submitted using a
form that sets out at least two major implementations
accepting the proposed change and states explicitly
that none oppose it. The three  major implementations
recognized are Blink, Gecko and WebKit; see
https://en.wikipedia.org/wiki/Comparison_of_browser_engines
[and ...?]
This stringent requirement will ensure that MathML Core
Level 1 will achieve a degree of browser interoperability
consistent with the widespread use of mathematical formalism
in science and technology.
"""

Overall, I personally don't see any difficulty in
putting something like "features added to Core
need to be supported by two major implementations
and opposed by none" into the proposed WG Charter
under Decision Procedures.  Being as bureaucratic
as the straw-man paragraph suggests is likely to
reduce agility, it seems to me.  In essence that
form-based procedure sets up a signing requirement
by browser developers.  Indeed, as given, it could
be criticized for not making explicit the organizational
contact points for statements of support.  For that
matter, it does not specify to whom the request shall
be submitted and who will judge and act upon it---
presumably that will be the spec editors.

One general aspect that seems to me a possible source
of confusion is the use by WHATWG of the term "semantics"
as though it is a clear mapping: each element has a
single clear meaning, and wider contexts are not relevant.
Perhaps the notion is that context is completely
taken into account by observing that it is an
HTML namespace that is the environment.  So the
significance of, say, subheading <h2> or anchor <a>
is held to be completely clear.

WHATWG write "Originally, HTML was primarily designed
as a language for semantically describing scientific
documents. Its general design, however, has enabled
it to be adapted, over the subsequent years, to
describe a number of other types of documents and
even applications."
[https://html.spec.whatwg.org/dev/introduction.html]
and later add
"Elements in the DOM represent things; that is, they
have intrinsic meaning, also known as semantics."
[https://html.spec.whatwg.org/multipage/dom.html#represents]
and
"Authors must not use elements, attributes, or
attribute values for purposes other than their
appropriate intended semantic purpose, as doing so
prevents software from correctly processing the
page."
The reason for this convention:
"Because HTML conveys meaning, rather than
presentation, the same page can also be used by a
small browser on a mobile phone, without any change
to the page. Instead of headings being in large
letters as on the desktop, for example, the browser
on the mobile phone might use the same size text for
the whole page, but with the headings in bold."

We seem, in considering documents with math, to have
the problem that the semantics varies with the intended
use: rendering to pages, speech or computational
platforms.  There's even variation within one
output target (say page rendering) in what an
element, say <msubsup>, should effect depending on
its local meaning.  The argument from the general
principle of element semantics quoted above would
seem to be that there should be different elements
according to the mainings, i.e. Content MathML
(extended and improved, of course).

All the best,

Patrick

P.S.  I am prevented from attending today's meeting
though I may try anyway to be there from a car journey.


On Thu, Sep 3, 2020 at 9:27 AM Frédéric Wang <fwang@igalia.com> wrote:

> I haven't had time to follow the cg discussions recently, but IIUC the
> answer on the Google doc and in the thread was that it shouldn't be in
> the decision policy. I don't know what the status is right now.
>
> My proposal was just that MathML Core must follow the minimal
> requirements for a "good" web platform specification, like what is done
> in other groups where browser vendors are involved. Otherwise, either
> there is a risk to go back to a low-quality standard (which is bad for
> the CG's image since we have been communicating we are fixing past
> mistakes) or a company has to veto proposals (which is creating
> frustration within the group). I feel like stating these minimal
> requirements somewhere would help those who are not familiar with
> browser development, as I have the impression many CG members just don't
> understand them, think decisions are arbitrary or can't estimate the
> implied effort required by spec changes. It's absurd to hear things like
> "Igalia is blocking this because they don't want to implement it" when
> we are currently the only company trying to do the required effort for
> MathML in browsers and when these minimal requirements have been set by
> others.
>
> On 03/09/2020 14:37, Moritz Schubotz wrote:
> > Hi Frédéric,
> >
> > was your question answered? I would be curious to find out as well. I
> > have something about consensus in my memories, but this might be too
> > vague.
> >
> > Moritz
> > http://moritzschubotz.de | +49 1578 047 1397
> >
> > On Fri, Aug 21, 2020 at 12:12 PM Frédéric Wang <fwang@igalia.com> wrote:
> >> On 17/08/2020 18:43, Neil Soiffer wrote:
> >>
> >> I have resolved most of the comments in the charter document. Based on
> feedback, I added that changes to Content MathML were out of scope for this
> charter.
> >>
> >> Please look it over and comment on anything you think is missing from
> the charter.
> >>
> >>     Neil
> >>
> >> I skimmed over the document, but can't find anything addressing my
> suggestion regarding the decision policy for MathML Core ?
> >>
> >> --
> >> Frédéric Wang
>
>
> --
> Frédéric Wang
>
>
>
>