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 mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion