Re: Charter changes/resolutions -- last call

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