Chronological Thread 

< Chronological >      < Thread >

---

Hi Andrew,

> I have now defined a mapping between CellML 1.1 and one draft of CellML
> 1.2. I have put this up at:
> http://www.cellml.org/Members/miller/mapping-1-1-to-draft-1.2/mapping
>
> It currently has all the mappings from 1.1 to a particular 1.2 draft,
> although it may be missing some of the reverse mappings.

I haven't had time to go through everything in detail (i.e. check that
everything that is in the original CellML 1.1 Specification is also in your
draft), but as far as I can tell (i.e. as far as I can remember the original
CellML specification) it all seems fine to me and it will no doubt be very
useful to anyone interested in CellML (it would certainly have saved me a
lot of time when working on COR's CellML API!). Anyway, here are some
comments which I hope will prove useful to you in some way or another (sorry
in advance for the number of them!):

- Section 1: you may want to provide a link to RFC 2119
(http://www.ietf.org/rfc/rfc2119.txt I believe).
- Section 1: shouldn't we have a definition for a CellML 1.0 Namespace? I
guess you may not have given one because your document is currently about
CellML 1.1 and will then be targeting CellML 1.2?
- Section 1: would it be worth to provide a link where the reader could look
up the Unicode characters given in some definitions (e.g. the Basic Latin
alphabet; possible link: http://www.unicode.org/ and in particular
http://www.unicode.org/charts/)?
- Section 2.2.1.d: did you really mean "element information element" or
"element information item"?
- Section 2.3: should its title be "Element information items" instead of
"Character information items"?
- Section 2.4.3: once again (see comment on Section 1 above), there is no
reference to CellML 1.0.
- Section 2.4.4.a: I don't know whether this is the rendered version of your
document that is responsible for it or not, but it might be worth
emphasizing keywords such as local names (here, "RDF")?
- Section 2.5.4: I don't see the point of having "when the parent
information item is not modified" and would therefore suggest to delete that
bit. Indeed, it's a "SHOULD", so the CellML Processing Software may, for
whatever reason, decide not to implement that 'rule'.
- Section 2.6.1: you may want to be consistent in the way you refer to
attributes in general. Compare this section with Section 4.2.1 for example.
- Section 3.3: are we missing 3.3.b and 3.3.c (in
http://www.cellml.org/Members/miller/mapping-1-1-to-draft-1.2/mapping/toplev
el.xhtml at least)?
- Sections 3.3.b and 3.4.b: shouldn't U+002D be introduced in Section 1?
- Section 3.4.c: shouldn't U+002E be introduced in Section 1?
- Section 3.5.e: shouldn't 'e' and 'E' be referred to as U+0065 and U+0045,
respectively? Again, shouldn't those be introduced in Section 1? I am not
convinced and, as a result, I am not convinced about U+002D and U+002E
either anymore.
- Section 3.2-3.5: shouldn't we have a rule similar to 3.1.c?
- Section 4.2.2: not critical/essential, but I would personally have the
order 4.2.2.d first, followed by e, a, c and b, i.e. the order in which a
model might be written if it was to be written from scratch.
- Section 5: for consistency, you might want to consider having "... local
name component..." rather than "... local name equal to component..." (see
2.4.4.a). If you were to go ahead with it, then it should also be done in
the rest of the document (i.e. Sections 6-17).
- Section 5.1.2: not critical/essential, but I would again personally have
the order c, a and b.
- Section 6.1.2.a: as for Section 2.4.4.a (see above), it might be good to
emphasize the different values (here "in", "out" and "none") that a
particular (here "public_interface") may have. Again, there are other places
where this also applies (i.e. 6.1.2.b, 12.1.1, 16.1.2, 18.3.1.c, 18.3.4,
18.4.10, 18.6.2, 18.6.3.c.i-iv and maybe others that I might have missed!).
- Section 10.1.1: if only encapsulation grouping is to be supported (dixit
your mapping document), we might then allow one and only one
relationship_ref element (rather than one or more of them).
- Sections 11 & 12: shouldn't those sections be swapped, so that
relationship_ref elements are discussed before component_ref elements (i.e.
the order in which they are introduced in Section 10.1)?
- Section 12.1.1: you make a reference to the fact that the relationship
attribute "MUST either take the value encapsulation or containment".
However, in your mapping document, you mention that "containment [is] not in
this draft version [and that] this needs further discussion".
- Section 13.1.2: the formatting is not consistent with say 10.1. One might
expect a list, as well as a reference to Sections 14 and 15.
- Section 16.1.1: lack of consistency. You have "... the value of the name
attribute MUST NOT be identical to the name attribute of any other units
element child of that model element..." while in Section 6.1.1.a you have
"... The value of the name attribute MUST NOT be identical to the name
attribute on any sibling variable element." In other words, in one case you
refer to the child of a parent element while in another you refer to sibling
elements.
- Section 16.1.3: for consistency, you may want to rephrase "A units element
MAY contain one or more unit element children" to "A units element MAY
contain one or more unit elements" (see Section 10.1.1 for example)?
- Section 18.1.5: typo: "It is noted..." and not "Its is noted..."
- Section 18.2.2: typo: should it read "In all other cases, [a variable
reference] SHALL consist of..."?
- Section 18.3.1.c: to use quotes might be the way to emphasize things (see
Sections 2.4.4.a and 6.1.2.a).
- Section 18.3.1.c: do we really need this condition considering that you
mention in your mapping document that "name [is] not defined for now..."?
- Section 18.3.4: as for Section 18.3.1.c, maybe the reference to the name
attribute should be dropped?
- Section 18.3.4-9: should we refer to encapsulation considering that,
again, you mention in your mapping document that "... there is a proposal to
only support encapsulation grouping"?
- Section 18.4.5: I am not quite clear what you mean by "without regard to
whether the variable_1 attribute of one map_variables element references the
variable referenced by the variable_1 or variable_2 attribute of the other".
Could you please clarify?
- Section 18.4.8: is there really a need for this section (it's analogous to
Section 18.4.7)? I guess it might be there just for completeness, which
cannot harm.
- Section 18.4.14: typoe: "... there MUST be exactly..." and not "... there
MUST be at exactly..."
- Section 18.5.2: I find that rule confusing and (mis?)understand it as
being that all of the units scoping rules must apply to a units reference,
which can obviously not always be the case (Section 18.5.4.a won't apply
most of the time for instance), not to mention that this contradicts Section
18.5.3 which implies that 1 to 4 rules may apply...
- Section 18.5.4.b: I find the phrasing cumbersome. Why not stick to
something similar to Section 18.5.4.a, i.e. "where a units reference appears
in an information item which is descended from the model element, and there
is a units element child of that model element with a name attribute
identical to the units reference, then the units reference SHALL refer to
that units element"?
- Table 1: for Celsius, should the offset be -273.15? I guess it all depends
on how one interpret the offset...
- Section 18.6.3.a: do you really mean a "prefix 1" and not a "multiplier
1"?
- Sections 18.6.3.c.i & 18.6.3.c.iv: inconsistency when it comes to
referring to 0/zero. In the former case, "zero" is used while "0.0" is in
the latter.
- Sections 18.6.3.c.ii-iv: do we really need the decimal for "1.0", "10.0"
and "0.0"? If so, then we may as well be consistent and a decimal in Section
18.6.3.a.
- Sections 18.6.3.c.v-vii: I haven't checked this in detail, but this looks
'too simple' to me. Has this been checked against Jonathan Cooper's paper
(DOI: 10.1002/spe.828)?
- Section 18.8.1: is it really necessary?
- Sections 18.8.4 & 18.8.5: analogous rules, so you may want to make the end
of the rules consistent.
- Sections 18.9.2.a-c: maybe I should think about this a bit more, but don't
those sections mean that all component elements are "pertinent component
elements"?
- Miscellaneous: would it be worth referring to various parts of Section 18
wherever suitable in the document (Sections 18.5-8 are referenced, but not
the others)?
- Miscellaneous: you use an hyphen in "top-level" while there are other
cases where an hyphen would also be useful (e.g. "built-in").

Best wishes, Alan.

---

• [cellml-discussion] CellML 1.1 to draft CellML 1.2 normative specification mapping, Andrew Miller, 02/13/2008
  • [cellml-discussion] CellML 1.1 to draft CellML 1.2 normative specification mapping, Alan Garny, 02/21/2008
    • [cellml-discussion] CellML 1.1 to draft CellML 1.2 normative specification mapping, Andrew Miller, 02/21/2008
      • [cellml-discussion] CellML 1.1 to draft CellML 1.2 normative specification mapping, Alan Garny, 02/21/2008

---

Archive powered by MHonArc 2.6.18.