Improve marking and tagging of rules in the standard text

[chrbertsch]

according to the discussion in https://github.com/modelica/fmi-design/blob/master/Meetings/2022/2022-10-25_27-F2F-FMI-Design-Meeting/minutes.adoc in order to be able to create better references to violation of rules in checkers

[nickbattle]

From my notes of the meeting, this issue can be used to raise areas which are unclear in the Standard, where the formal rules are therefore uncertain - in the hope that these can be clarified. I will try to add one comment for each distinct aspect that could be clarified, rather than raising separate issues for each one.

[nickbattle]

The definition of continuous-time states is confusing. The mathematical model (Table 4) refers to them as Xc, and the <ModelStructure> refers to them via their derivatives in <ContinuousStateDerivative>. But it is not clear whether the complete list of continuous-time states is defined via the ModelStructure or whether this can be calculated somehow from the ModelVariables. The InitialUnknowns include the "continuous-time states or state derivatives (defined with elements ) with initial = approx or calculated". There is nothing in the Glossary about this term either.

Currently, the formal model tries to derive the continuous-time states from the ModelVariables, looking for Floats that are "continuous" (or default variability) that also have a derivative variable. But perhaps the continuous-time states ought to be derived from those listed in the <ContinuousStateDerivative> section.

There is a similar comment about the "continuous state derivatives".

[nickbattle]

The rules about the inheritance of model variable fields from any declared types could be clearer. This is mentioned in Table 21, but presumably not all fields are inherited from their types - "name" clearly isn't inherited; "definition" could be, though wouldn't be sensible? "annotations" could be, but again, that wouldn't be sensible? Clock's "intervalVariability" is mandatory in both the type and the variable, so the type field can have no effect?

Then, it would help if it was made clear that rules about various variable field values apply to the "effective" values of those fields after the inheritance with any derivedTypes have been resolved (assuming that's true!). The example I gave in the talk was that the "min <= max" rule hides the fact that either value may have come from the type, or may have defaulted to a MIN/MAX value for the type.

[nickbattle]

A small point, but Table 15 explains that the "name" field of type definitions must be unique within both the list of type definitions and the list of variables. The corresponding entry in Table 17, for variables, does not mention this extra uniqueness. It probably should.

Section 2.4.7.3 about variable aliases says their names must be "unique among all variables and variable aliases". So does that mean that the names of types, variables and aliases form three disjoint sets? If so, wording should probably be tightened. The formal rules will currently allow a type name to be the same as an alias name.

[nickbattle]

Looking at the x1,y1,x2,y2 attributes of TerminalGraphicalRepresentation, GraphicalRepresentation and Icon, I originally had rules to say that these should all define a bottom-left to top-right non-zero area. But after discussion with Christian Schulze, I gather some of these coordinates can be flipped, though we can sensibly say they are never define a zero area.

To quote the conclusion of our email:

"So now the rules say that a CoordinateSystem is not flipped and not zero area, whereas an Icon can be flipped but is not zero area. I think I was confused because the Icon flipping appeared in the CoordinateSystem section, even though it was referring to Icons. It is also confusing that a TerminalGraphicalRepresentation is separate as well (section 2.4.9.2.5). Now a TerminalGraphicalRepresentation can be flipped, but is not zero area."

The wording in these sections could clarify this.

[nickbattle]

The discussion of min/max in Table 15 with Enumerations gives an example of name/value Items which do not lie within the min/max range, saying that only name/values within the range are "allowed". This suggests that out of range values can be legally defined, but not legally used. That seems unusual (why would you ever do this in a discrete enum?) but the formal rules are currently written this way. If this is not as intended (i.e. it's just a poor example), it should be clarified.