Chronological Thread 

< Chronological >      < Thread >

---

On 02/06/11 02:30, Alan Garny wrote:
> Hi Andrew,
>
> ...
> I am not into that kind of modelling, so just a few general comments from
> me:
> - Do we really want to go with csymbol? From your document, I understand
> that it might be to keep compatibility with CellML 1.0 and 1.1? If so, then
> I really don't see why you would want that, since most (all?) of the
> existing CellML-capable software are unable to deal with uncertainty. So, it
> might just be better (cleaner) to use 'proper' element names?

Hi Alan,

I consider csymbol to be the cleanest way to add new operators that
aren't a standard part of MathML - certainly that is the approach that
is taken in SBML and all the other proposals I've seen. Inventing a new
operator element could be an alternative approach, but the MathML
specification doesn't seem to encourage that way of doing things.

> - Why "uncert1" (as opposed to, say, "uncert" or something that doesn't
> have a "1" in it) in the csymbol definition URL?

The 1 is intended to be a version number in case we come up with a later
incompatible specification and want to bump the version number.

> - Regarding your two examples, it would help the reader if you were to
> mathematically introduce them rather than just provide the corresponding
> CellML code.

I'm planning on updating the document shortly, and I'll look into making
this change in the process - probably just by providing a rendered
version of some of the equations or a bit of surrounding text.

> - Regarding the CellML code you give as an example, it might help to put
> the units definitions before the component definition.

I'm concerned that if I do that, the units will detract a bit too much
from the main point, and they are really intended to be a minor detail.

> Also, it would be
> good to respect the indentation (especially for the math element), and use a
> smaller font or reduce the margins, if necessary.

I certainly don't think it can be any wider on the page without wrapping
or overflowing; currently everything is using the default settings of
the DocBook renderers being used, and I'm trying to avoid having to
change that, so it can be 'standard DocBook'.

Best wishes,
Andrew

>
> Alan
>
> _______________________________________________
> cellml-discussion mailing list
> cellml-discussion at cellml.org
> http://lists.cellml.org/mailman/listinfo/cellml-discussion

---

• [cellml-discussion] First unofficial draft of specification on CellML parameter uncertainty, Alan Garny, 06/02/2011
  • [cellml-discussion] First unofficial draft of specification on CellML parameter uncertainty, Andrew Miller, 06/13/2011
    • [cellml-discussion] First unofficial draft of specification on CellML parameter uncertainty, Alan Garny, 06/13/2011

---

Archive powered by MHonArc 2.6.18.