Chronological Thread 

< Chronological >      < Thread >

---

Hi Andrew,

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

Ok, fair enough (especially if the MathML specification seem to encourage
the use of csymbol).

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

Ok, I can now understand the rationale, but is there really no better way to
achieve the same result? In fact, do we need to worry about it at all?
Surely, if we were to do things right in the first place, then there
wouldn't be a need for such a mechanism?

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

... or both...?

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

I wouldn't be concerned. People who are going to read your document will,
hopefully, know enough about CellML to realise that this is not the main
point and will therefore look for it. Yet, they will know that units have
been defined, so when they get to the main point they won't be surprised to
see that 'new' units are being used (FWIW, I was).

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

Ok, but I find it to be a bit of a mess at the moment. Proper indentation
helps when you have to read some XML code.

Alan

---

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