Chronological Thread 

< Chronological >      < Thread >

---

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