Re: Reminder: MathML intent meeting 5 Nov, 2020

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.)
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.

> 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.


> 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/

Received on Thursday, 5 November 2020 12:56:15 UTC