Chronological Thread 

< Chronological >      < Thread >

---

>>> The issue is complicated by what to do with bracketed expressions(which
>>> I currently allow, to override ambiguity). For example, a user could
>>> enter...
>>> x = (((((a + b) + c) + d) + e) + f)
>>> I would be interested to know if you believe that the first content
>>> MathML encoding or the second is more appropriate.
>>>
>> I think if the user has specifically entered the brackets then they
>> should be reflected in the generated MathML.
> Could you please elaborate on why you think this? I can think of three
> rationale:
> 1) Presentational reasons, i.e. to improve the way the math is
> viewed for the user.
> => Note that content MathML doesn't really guarantee this
> anyway, and there are other semantically 'redundant' brackets, such as
> in a+(b*c) that couldn't be stored in content MathML at all.
> 2) You are concerned that it will change the semantics due to
> definitionURL or due to generalising the CellML model to something where
> variables aren't a group on addition/multiplication/division/subtraction?
> 3) You feel that users should have that level of control over the
> MathML, even when the semantics don't change?

I'm thinking 3, but it is influenced by 1

> I personally don't think a content MathML input language should even try
> to address 1.

I disagree with that - are we not essentially discussing a presentation
format for MathML that makes it easier for users to interact with? but
then as you point out, using content MathML as the source you can't
guarantee to get back the same format as the user enters - in which case
is there any point trying to maintain the formatting entered by a user?
so then maybe you do have a valid point, but that leads me to wonder
what advantage this approach then gives you over editing the MathML
directly?

> I am somewhat neutral on rationale 3, because I don't like the idea of
> going into edit mode on equation, not changing anything, but still
> having the form of the MathML get changed, but at the same time, if the
> semantics are guaranteed not to change, I am not convinced that it matters.

we're trying to develop a interface that the user is comfortable using.
So if I open up a model and mentally go through all the syntactical
rules for precedence and operator ordering and then add in some brackets
so that I don't have to go through that process again, I want to be able
to save that presentation of the math and be able to get back to it
without having to add in all the brackets again - except we can't do
that using content MathML as the source...so is it a case where we
provide an interface that lets the user edit the content MathML, get a
default transformation to presentation MathML and then if the user wants
to refine that presentation they are able to further edit the
presentation MathML for a particular equation and have that saved along
with the content MathML using the semantics element of MathML?

I think people need to sit down and think about the target audience for
using this kind of equation editing interface. As far as I can see there
are going to be three types of users: (1) those happy to work directly
with the content MathML, perhaps aided by a convenient transformation to
presentation MathML for viewing; (2) those happy to work with a common
language they are already familiar with (such as Matlab and/or C) and
expect the editing environment to behave the same as that language does
natively; and (3) those who want a pretty GUI such as the equation
editor found in MS Office applications (or the original Java-based
content MathML editor).

I'm not sure that developing a new syntax and spending time worrying
about where to preserve and throw away extraneous brackets fits into any
of these targets. And in all cases, I would think that most users would
expect that when they type in or edit an equation that they can save the
equation and come back to it later and have it look the same as when
they saved it.


Andre.

--
David Nickerson, PhD
Research Fellow
Division of Bioengineering
Faculty of Engineering
National University of Singapore
Email: david.nickerson at nus.edu.sg

---

• [cellml-discussion] Content MathML editing language: Binary => n-ary syntax, Andrew Miller, 11/20/2006
  • [cellml-discussion] Content MathML editing language: Binary =>n-ary syntax, David Nickerson, 11/20/2006
    • [cellml-discussion] Content MathML editing language: Binary =>n-ary syntax, Alan Garny, 11/20/2006
    • [cellml-discussion] Content MathML editing language: Binary =>n-ary syntax, Andrew Miller, 11/20/2006
      • [cellml-discussion] Content MathML editing language: Binary=>n-ary syntax, David Nickerson, 11/20/2006
        • [cellml-discussion] Content MathML editing language: Binary=>n-ary syntax, Poul Nielsen, 11/21/2006
  • Message not available
    • [cellml-discussion] Content MathML editing language: Binary => n-ary syntax, Andrew Miller, 11/20/2006
  • [cellml-discussion] Content MathML editing language: Binary => n-ary syntax, Shane Blackett, 11/24/2006

---

Archive powered by MHonArc 2.6.18.