Re: Charter changes/resolutions -- last call

Elika, thanks for your suggestions. I have accepted most and reworded one
of them. Some decisions are relevant to AT, not browser engines, so the
proposed wording for those resolutions was not appropriate as written.

I believe the new wording should satisfy Frédéric's objectives and is
consistent with what was written by Elika.

    Neil


On Thu, Sep 3, 2020 at 1:18 PM Brian Kardell <bkardell@gmail.com> wrote:

> Elika was kind enough to give our draft a read a do lots of text
> corrections/proofreading for us  (in suggestions mode) as part of
> discussing her thoughts on whether the charter could/should say something
> on the issue raised about being more specific about MathML Core and browser
> vendors.  Almost all of those were very plain and I just accepted them.
> There are a few which I did not as I feel like there is at least a
> possibility that someone will think they should be discussed.
>
> Together (again, still in suggestion mode) Elika and I added a sentence to
> the end of the deliverables section which is explicit about this "Where
> the MathML Core specifications are intended to define only those parts of
> MathML that are or will be implemented by all major browser engines."
>
>
> And in the decisions section we have proposed "The group will work to
> ensure that the contents of its MathML Core specifications will be
> interoperably implemented by all major browser engines by striving for
> positive support from at least two major vendors with none opposed."
>
>
>
>
>
>
>
> On Thu, Sep 3, 2020 at 12:07 PM Patrick Ion <pion@umich.edu> wrote:
>
>>
>> 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
>>>
>>>
>>>
>>>
>
> --
> Brian Kardell :: @briankardell :: bkardell.com
>