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. I believe it would be easier for the reader if you were always to refer to something in the same way rather than by using different (equivalent) formulations. > In 6.1.1.a, variable element information items can only occur as a > child > of a component element information item, and so there is no need to > mention the component element information item. It is therefore in the > interest of brevity to not mention the component and use the word > sibling. > > In 16.1.1, we have to reference the parent element already, because the > exact scope in which unit names must be identical depends on the parent. > Because we already have made reference to the parent element, it seems > to make sense to discuss the other children of that parent (although > perhaps there is still a wording that would be just as readable based > on > the concept of sibling elements). I think that would be good (to reword that section so that it is "as readable based on the concept of sibling elements"), but certainly not a priority. > > - 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? > > > The text is trying to say that the rule about not duplicating > connections applies even if the component_1 / variable_1 and > component_2 > / variable_2 pairs are reversed in the duplicating connection. I > personally don't find this unclear, but that may be because I wrote it, > so perhaps you would be better placed to suggest an alternative formal > definition of the rule? I have just re-read the rule together with your explanation, and it now makes sense to me. I want to think it's only me who, for some reason, didn't understand what you meant in the first place. > > - 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... > > > I agree, you are correct that the wording allows that interpretation, > which is not the intended interpretation. > > The intended interpretation was (not (there-exists units-reference u: > (not (there-exists scoping-rule r: (r applies to u))))) rather than > (not > (there-exists units-reference u: (there-exists scoping-rule r: (not (r > applies to u))))). > > It is actually quite add to unambiguously express the intended > interpretation as is in English, but it is logically equivalent to: > (forall units-reference u: (not (not (there-exists scoping-rule r: (r > applies to u))))) <=> (forall units-reference u: (there-exists > scoping-rule r: (r applies to u))) which could be written as: > "Every units reference in a CellML Infoset MUST have at least one > scoping rule which is applicable to it". This seems unwieldy too, we > could go for the double negative form above: > "Every units reference in a CellML Infoset MUST NOT be defined so that > there are no scoping rules applicable to it." > > Alternatively, perhaps we want to formulate it from (not (there-exists > units-reference u: (forall scoping-rule r: (not (r applies to u))))), > which would be: > "A CellML Infoset MUST NOT contain a units reference to which all > scoping rules are inapplicable." > > I think that this last form might be the clearest, so I have put it in > my draft. Though like you I find your last suggestion to be the clearest, I would like to suggest a slight revision to it: "A CellML Infoset MUST NOT contain a units reference to which none of the scoping rules are applicable." > > - 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)? > > > Perhaps, although the interpretation section (18 in the draft you refer > to) differs quite markedly in structure from anything in CellML 1.1 so > it is not always clear what should reference what. > > - Miscellaneous: you use an hyphen in "top-level" while there are > other > > cases where an hyphen would also be useful (e.g. "built-in"). > > > I have now changed all occurrences of "built in" in my draft to built- > in. Keep in mind that "built-in" was just one example. I recall seeing other such cases where an hyphen would normally be required. This being said, I would agree that this is not a high priority at this stage. Alan _______________________________________________ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion