In 13.10 VARExpressions, there does not seem to be a consistent term for the "referent" of a VAR-expression, what EXPRESS calls a "variable" and C calls an "lvalue" - an identifiable place that holds a value. It is the analog to the "evaluation" of an Expression, which is an Instance. In the metamodel, the term Variable here seems to have a more restricted meaning, and the term "referent" is used in multiple ways, most egregiously in the definition of AliasRef:refers-to. Some term should be chosen and used consistently for this purpose, and any conflicting use in the metamodel should be renamed. It appears that the term being used in this section (only) is "Cell". For consistency with Part 11, the term should be "Variable", but using that term might also be confusing.

There is no inconsistency in the use of "referent"; the inconsistency is in the term for the thing that is a "referent" - "object", "place", "variable", "cell", etc. All of these will be changed to "cell".
AliasRef:refers-to can be changed to "referent", although the text is clear that the referent of the AliasRef is self->refers-to->referent, and the "refers-to" contrasts with VariableCell:referent.

In 10.4.11 Generic Element
Is every GenericType or AGGREGATEType that has a type_label a GenericElement? It seems that that is the rule, but the definition in 10.4.11 is not clear on this point.

GenericElements are syntactically represented as parts of a data type specification, but they are not GenericTypes or AGGREGATETypes. They are separate semantic concepts that are related to type specifications. A data type represented as GENERIC:tag, for example, is a reference to the GENERIC type, and it also represents an ActualDataType whose id is the "tag".
For each syntactic occurrence of GENERIC, GENERIC_ENTITY or AGGREGATE that defines a type_label, there is a corresponding GenericEntity that has that type_label. Other syntactic occurrences with that type_label represent ActualTypes and ActualTypeConstraints that refer to that GenericEntity.
The model of GenericElements will be corrected in this regard. The relationship between GenericElements and GeneralizedTypes is dealt with more extensively in the resolution to Issue 14068, and the model elements that can have GeneralizedTypes and GenericElements are corrected in Issue 14194.
Revised Text:
The corresponding model and text changes are included under Issue 14194.

Disposition: Merged into Issue 14194

In Figure 26, InParameter inherits :formal-parameter-type (ParameterType) from Parameter. In Figure 27, InParameter inherits variable-type (VariableType) from NamedVariable. InParameter cannot have both.
Proposed Resolution:
Actually it can. The problem is that InParameter has two faces: the formal parameter has a ParameterType, but the corresponding internal Variable in each invocation has a VariableType - any GeneralizedType becomes the ActualType of the actual parameter. And VARParameter has the same behavior - the Parameter can have a GeneralizedType, but each instantiation refers to a "variable" that has an ActualType. Modify the text to explain this better.

After some discussion of elaborating the model, the FTF concluded to adopt the proposed resolution and modify the text to explain the two relationships for InParameter.
But VARVariables do not have variable-types; VARVariables only have referents. Also, ControlVariables are Variables (they can be passed to VAR Parameters, even though they cannot be assigned to). This all means that variable-type should be an attribute of Variable instead of NamedVariable. QueryVariables do have variable-types, and in order to simplify the model, they are to become a subclass of Variable, instead of NamedVariable, although it is syntactically impossible for a QueryVariable to be the referent of a VARCell.
Finally, 10.2.5.3 documents Parameter:variable, an association that no longer exists with the Beta-2 model of InParameter and VARParameter. This will also be corrected.

In 12.7 Function Calls and 13.7 Procedure Calls, it becomes clear that ActualParameter (12.7.1) is an abstraction of two distinct concepts: One associates an Expression with an InParameter (and behaves like an Assignment) and the other associates a VARExpression with a VARParameter (and behaves more like an AliasStatement). Procedures have both, but Functions have only InParameters, and thus only associations of the first kind. Splitting this concept into its two subclasses would simplify clause 12.7 and clarify clause 13.7.

There is consensus that explicitly modeling "call by value" and "call by reference", which are the two concepts to which the issue refers, is a minor technical change. This change is an improvement in the model that removes a (compliance point) packaging problem, simplifies the text and assists in mappings.

In 12.5, the id attribute of AttributeRef and GroupRef should be documented as subsets Expression:text, and not as derived from it, in both the text and the class diagram (figure 36).

Merged into Issue 13689

Disposition: See issue 13689 for disposition

Clause 9.8.2 I don't know what the "Napierian exponential function" is. Perhaps it is more usual to native English speaker? Yet I didn't find anything worthwhile when I googlized it (is Google anyway a reference?). I just know the "exponential function" and the "naperian logarithm function" which is the inverse of the preceding.
Yet defining e from one of these functions whose definitions are, AFAIK, based on e itself doesn't make sense.
I'd recommand to use the original Euler's definition: see http://en.wikipedia.org/wiki/E_(mathematical_constant)#History
If agreed, that could be handled through an issue for the 2nd FTF.

The definition of E in the specification was taken verbatim from ISO 10303-11 Clause 14.2. However, the issue is correct: Napier published a table of natural logarithms, but the exponential function is credited to Euler. The specification should use one of Euler's definition (based on the area under the curve 1/x), or Bernoulli's definition (the limit of (1+1/n)n).