Re: [cellml-discussion] CellML 1.1 to draft CellML 1.2 normative specification mapping
Hi Andrew, > > - 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)? > > > You are right that in many cases I have used "attribute" as a short- > hand > for "attribute information item" in a number of places. Because we are > talking about XML Infosets, it is technically correct to refer to > "attribute information items". Attribute information item would get a > little unwieldy in places - would you be happy with defining attribute > to mean attribute information item in the terminology section? Yes, after all you have already taken that kind of approach (e.g. Section 5 where you refer to "component element information items" as "component elements"). > > - 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. > > > We do need to be careful that everything is unambiguous. There are lots > of characters which people might potentially try to use for full stop > and hyphen-minus (I have heard of models purporting to be CellML models > with all sorts of Unicode characters in place of that character, > usually > as a result of people copying physical constants from online sources or > word processors), although saying Basic Latin may be enough to make it > unambiguous. I think that Basic Latin 'e' and 'E' are definitely > unambiguous, although perhaps there is still a case for consistency of > notation, perhaps by saying 'e' (U+0065) or 'E' (U+0045). That's what I was after: consistency. If you were to say something like "'e' (U+0065) or 'E' (U+0045)", then you might want to do the same with say "'-' (U+002D)". This way, one wouldn't have to look up the particular Unicode character you refer to (indeed, though I knew what you were referring to, I did look up the different Unicode characters you refer to). > > - 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. > > > I think 4.2.2 is essential - without it section 2.4.1 would mean that > model element information items could only contain whitespace, RDF and > extension element information item children. > > In terms of the ordering, I did think about ordering schemes for the > elements, and the reason I went for an alphabetical ordering was to > choose an arbitrary ordering of something which doesn't matter. > > You suggest the ordering import, units, component, group, connection, > although I know of people who prefer very different orderings. Perhaps > keeping things like this alphabetical might be the safest approach from > the point of view of producing an uncontroversial draft. I didn't realise it was in alphabetical order. I agree that this is most likely the safest approach. > > - Section 5.1.2: not critical/essential, but I would again personally > have > > the order c, a and b. > > > or we could alphabetise this one properly - I guess that the MathML > entry should be sorted as 'm', then units, then variable. I am now > assuming that you mean the order is not critical, and not the section > itself? Yes, that's indeed what I meant (and the same obviously holds true for my comment above on Section 4.2.2). Otherwise, I agree on your alphabetical order. > BTW, the text is supposed to mean that the order in the CellML Infoset > is not important. > I don't think "... MAY contain zero or more specific information item > children, each of which MUST be of one of the following types ..." > could > be interpreted as requiring that all of one type of children must > appear > before the first of the next type of child, but perhaps I am missing > something. Agreed, so I don't think you are missing anything here. > > - 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. > > > I think that sibling elements are semantically the same thing as the > other child elements of the parent element, so can be used > interchangeably depending on which one is the least unwieldy in the > context. Agreed, I was merely pointing out a lack of consistency.
Re: [cellml-discussion] CellML 1.1 to draft CellML 1.2 normative specification mapping
Alan Garny wrote: > 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). > Good point, I have now drafted a version which I will push to my public git shortly which adds RFC2119 as a normative reference. > - 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? > No, the specification mixes namespaces in accordance with the rules that: 1) Any element which hasn't changed semantics from CellML 1.1 keeps the CellML 1.1 namespace in CellML 1.2. 2) Any element which changes semantics goes in the CellML 1.2 namespace. CellML 1.1 already changed the namespace for everything from the namespace used in CellML 1.0, so it makes no sense to mix CellML 1.0 namespaces with CellML 1.1 or 1.2 namespaces. Because we never refer to CellML 1.0 namespaces, there is no point in providing a definition for them. > - 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/)? > I don't think this is necessary in a normative specification - I don't think providing such a link would serve the goals of a normative specification, but this would of course be a good thing for an informative specification. > - Section 2.2.1.d: did you really mean "element information element" or > "element information item"? > I have drafted a revision to fix this - thanks for finding that. > - Section 2.3: should its title be "Element information items" instead of > "Character information items"? > The section says... " An element information item in the CellML namespace MUST NOT contain any character information items, except for character information items which consist entirely of whitespace characters. ", which is the constraint on the occurrence of character information items in CellML documents, so the title in my draft seems to make sense to me at least. > - Section 2.4.3: once again (see comment on Section 1 above), there is no > reference to CellML 1.0. > This is because elements in the CellML 1.0 namespace do not comply with CellML 1.2. Software which is attempting to process a document in accordance with the CellML 1.2 specification should give an error if they encounter an element in the CellML 1.0 namespace (if those software packages want to implement CellML 1.0 as well, they of course can, but compliance with the CellML 1.0 specification is not related to compliance with CellML 1.2 because, for a given CellML Infoset, the two specifications are mutually incompatible). > - 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")? > DocBook has an element called literal, which I think can be used for this purpose. I have changed the RDF and math cases in general-matters.xml, but not the remainder yet, because many of them are changed in various other drafts, and it might be easier to wait for some of them to be integrated in as the set of literals will change as a result of that process. > - 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'. > The intention is that extension information on an element be preserved, as a matter of best practice, when a particular element in a document is not modified. If, on the other hand, that element is modified, then it would no longer make sense to try to preserve unrecognised extension information, because it relates to what an element used to look like. It is a SHOULD ru
Re: [cellml-discussion] CellML 1.1 to draft CellML 1.2 normative specification mapping
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
[cellml-discussion] CellML 1.1 to draft CellML 1.2 normative specification mapping
Hi all, 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. Best regards, Andrew ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
