Re: Reminder: MathML intent meeting 5 Nov, 2020

Hi Deyan, Bruce,

thank you for your responses.

On Thu, Nov 5, 2020 at 1:56 PM Miller, Bruce R. (Fed) <bruce.miller@nist.gov>
wrote:

> On 11/5/20 2:36 AM, Physikerwelt wrote:
> > [...] the proposed new attributes seem even more
> > complex to me.
> >
> > This makes MathML the black sheep in the HTML family once again. Does
> > the majority of this group really think it is a good idea to encode tree
> > structures as part of XML / HTML documents that are inherently trees?
>
> I'm not sure there's any consensus yet, and even the "proponents" aren't
> that fond of the idea.  But the big question seems to be:
>    How you encode tree structured data into an inherently tree structured
>    format without introducing new elements?
> (while avoiding the even blacker sheep Content MathML, even worse if
> cross-referenced.)
>

Oh. It seems that I love the blackest sheep. Honestly, while looking at
Deyans` demo I was thinking what is wrong with the content form (exept for
the fact that there are no crossrefs.



> Maybe we need a MathML analogue of span soup?
>
> The intent/semantic/whatever data that needs to be represented is a
> tree, but doesn't match the presentation tree, and apparently isn't
> exactly the content tree, which seems to leave us with the need to
> represent something new somewhere, somehow.
>

It might also be possible to have two CMML trees.



>
> > If the answer is yes, which I somehow assume, I still don't understand
> > why we can't use an existing language such as JS or (La)TeX or ... to
> > represent this tree structure.
>
> The syntax in the current discussion is actually quite simple,
> although the resulting expressions are indeed quite scary.
> There is some experimentation to try to simplify or default some
> things while not complicating the logic.
>
>  From my personal perspective, the main first question is to understand
> the data model itself, particularly what the tree structure and leaves
> are. The syntax is secondary and need not (should not?) be committed
> too early.
>
> You could swap ()=>{} and put "\" everywhere to get TeX, if that helps.
> By javascript, I assume you mean JSON?  That's a possibility that came
> up.  It might be a better choice at the implementation stage, but makes
> discussion of the model impossible, since it's unreadable.  There's also
> the problem of where the JSON would go. Encoding JSON (with it's own
> quote soup) inside attributes is not a pleasant prospect.  And if you
> put it elsewhere in the document, you've got to connect it to the MathML
> using ids, which seems to be an unpopular option.
>
I think LaTeX would be better. But I was referring to JavsScript as of
Javascript functions representing mathematical functions that are never
executed. Like in a CAS.

See you in the meeting.
Moritz



>
>
> > Having to define, encode, implement, and maitain a new MathML costom
> > logic seems to require a very good reason.
>
>
> --
> bruce.miller@nist.gov
> http://math.nist.gov/~BMiller/
>
>