Issues for Mailing list of the EXPRESS Metamodel 1.1 Revision task Force

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 13447: The metamodel doesn't seem to support a Schema -> Interface -> Schema relationship
Issue 13669: Associations that should be composite
Issue 13670: Some ActualTypes have namespaces
Issue 13671: EnumerationType:values is derived
Issue 13672: entity-has-attributes documentation
Issue 13673: Scope of Attribute is not modeled
Issue 13674: Correct derivation of plays-domain-role
Issue 13675: Parameter:explicit-role is not defined
Issue 13676: derivation of role bounds
Issue 13677: remove "derivedFrom" dependency
Issue 13678: Derivation of redeclaration bounds
Issue 13679: Remove instance-of-type
Issue 13680: derivation of Redeclaration:refined-role
Issue 13681: Correct derivation for value-of-EnumerationType
Issue 13682: Constrain of-type for SimpleValue subclasses
Issue 13683: True, False and Unknown are not defined
Issue 13684: Correct documentation of Extent:content
Issue 13685: correct documentation of extent-within-population
Issue 13688: GenericElement:source is not composite
Issue 13689: id attributes in 12.3 subset Expression:text
Issue 13690: Literal refers-to SimpleValue is not abstract
Issue 13691: Delete ParameterRef:id
Issue 13693: GenericElement:source is not composite
Issue 13694: id attributes in 12.3 subset Expression:text
Issue 13695: Delete ParameterRef:id
Issue 13696: AttributeRef/GroupRef:id subsets Expression:text
Issue 13697: Correct text of Operations and FunctionCalls
Issue 13699: Clarify ActualParameter:inFunctionCall
Issue 13700: Provide link for actual-referent
Issue 13701: 12.8, Query expressions
Issue 13702: AggInitializer:result-value subsets evaluation
Issue 13703: Incorrect model of AggregateInitializer
Issue 13704: PartialEntityConstructor attributes subset Expression attributes
Issue 13705: Delete associations to Instance classes in 12.10
Issue 13706: Indeterminate literal is not documented
Issue 13707: in 12.11 most values not specified as an instance object in the Instances package (Clause 9)
Issue 13708: Statements can appear outside StatementBlocks
Issue 13709: Correct model of AliasStatement and AliasVariable
Issue 13710: Correct the properties of Alias-binds-variable
Issue 13711: Correct semantics of optional RETURN value
Issue 13713: Distinguish AliasRef from VariableRef in text
Issue 13870: Question on InvertibleAttribute subclass of ExplicitAttribute
Issue 13880: Figure 28 is the wrong figure
Issue 13899: Attribute:attribute-type is not a DataType
Issue 13900: Text of Definition of RangeRole:range
Issue 13901: Nature of InstantiableType
Issue 13902: Wording of Redeclaration:lower-/upper-bound
Issue 13903: Literal:refers-to subsets Expression:evaluation
Issue 13904: SizeConstraint/LengthConstraint subset ParameterType:constraints
Issue 13905: Excess text in schema-interfaces-elements Definitions
Issue 13916: Correct UML qualified name syntax
Issue 13917: Use consistent class diagram style
Issue 13918: Correct Figure references
Issue 13919: Correct indexing/selector text
Issue 13929: InstantiableType:fundamental-type should be derived

Issue 13447: The metamodel doesn't seem to support a Schema -> Interface -> Schema relationship (express-rtf)

Issue Submitter: David Price, Eurostep


Document: EXPRESS Metamodel, Alpha Version


Issue:


The metamodel doesn't seem to support a Schema -> Interface -> Schema 
relationship. I do see Schema -> InterfaceElement ->   SchemaElement 
relationship in the metamodel but it's as often as not the  entire Schema 
that gets interfaced.


If I were using the metamodel in a tool to create EXPRESS, this seems to mean 
I can't establish schema interfaces  beforehand (e.g. to split a domain being 
modeled into subdomains) unless I have elements in every schema. This seems 
like a gap in the metamodel.


What I mean by this is that I should be able to take the EXPRESS metamodel, 
build an application that directly implements the classes it defines and then  
I should be able to create any and all valid EXPRESS schemas.


Since:
SCHEMA A;
  USE FROM X;
END_SCHEMA;
SCHEMA X;
END_SCHEMA;
 
is valid EXPRESS it seems to me the metamodel should support this. It doesn't  
seem to me that the distinction is purely syntactic if there are valid  
schemas that cannot be represented using the metamodel. I do agree with Ed 
Barkmeyers analysis of what the text in Part 11 says, it's just that the text 
appears to  be incomplete in that it doesn't cover the A and X situation 
above.


Related Discussion Summary:


>From Ed Barkmeyer: I would say that USE FROM <schema>; is just a syntactic 
shorthand. Â What  is actually interfaced is a specific collection of 
InterfacedElements.  It is not clear that any additional semantic 
relationship is established  between the two schemas. Â The only relationship 
between the two schemas is that some of the InterfacedElements in one Schema 
refer to  SchemaElements defined in the other one.


In the UML case, the relationship is package-to-package, and circular 
import/merge relationships are not valid. Â But EXPRESS is very clear that the 
relationship is schema-to-InterfacedElement, and circular  references among 
the schemas themselves are permitted. Â Also in UML, importing a package 
doesn't change the local package namespace. Â In EXPRESS, interfacing elements 
adds identifiers to the local schema namespace. Â So Exp:Schema and 
UML:Package are only superficially similar.


I guess we never discussed using the metamodel to "create EXPRESS", and 
I'm not quite sure what that means. Â But Bernd Wenzel pointed out at one point 
that certain purely syntactic information should be maintained in the 
metamodel to allow a reasonable approximation to the original EXPRESS 
schema to be constructed.


My understanding was that EXPRESS was being treated as the legacy.
So the intent of the metamodel was to capture the knowledge contained in
a set of EXPRESS schemas, for the purpose of rendering that knowledge 
into more useful forms.


It is not clear whether USE FROM X (<list of everything in X>); is a 
"reasonable approximation" to USE FROM X; . Â But it is certainly true 
that there is no way in the metamodel to represent USE FROM X; if X 
contains no declarations.


Note also that, unlike USE FROM X;, what REFERENCE FROM X; interfaces is 
selective, and there you want the metamodel to capture the 
interpretation -- the results of the algorithm described in clause 11 -- 
not just the parse. Â So I would never want to see a metamodel population 
in which some schema-to-schema relationship was captured INSTEAD OF the 
collection of schema-to-InterfacedElement relationships that that syntax 
MEANS. Â (But the other experts may not share my view.)


Proposed Resolution: No

Many associations in the specification should be specified as "composite", in order to facilitate XMI export and other implementation technologies.  The following is a list of associations (by their end names) that are clearly 'composite' in intent, as their definitions indicate:

(Core, clause 8)
EntityType:unique-rules
LocalScope:local-elements
NamedType:type-elements
NamedType:domain-rules
Schema:schema-elements
Schema:interfaces EntityType:declares 
SingleEntityType:declares
SingleEntityValue:properties

(Instances, clause 9)
ARRAYValue:member-slot
BAGValue:member-slot
EnumerationType:declared-items
LISTValue:member-slot

(Algorithms, clause 10)
Algorithm:formal-parameters
Algorithm:actual-types
Algorithm:body
AlgorithmScope:variables
Function:result
Parameter:type-constraints
Parameter:structure-constraints

(Rules, clause 11)
GlobalRule:supporting-body
GlobalRule:contains-rules
SupertypeRule:constraints

(Expressions, clause 12)
AggregateInitializer:bindings
FunctionCall:actual-parameters
PartialEntityConstructor:bindings
QueryExpression:query-variable

(Statements, clause 13)
CaseAction:action
CaseStatement:cases
IfStatement:then-actions
IfStatement:else-actions
ProcedureCall:actual-parameters
RepeatStatement:body
RepeatStatement:control-variable
StatementBlock:body-statements

Proposed Resolution:
For each of the above, modify the UML diagram to show the 'composition' association and modify the text specification of the association end by adding:
  Properties: composite

In 8.6.1.3 ActualType, the Note is incorrect.  Two of the subtypes of ActualType are identified by "label" and they *do* have a namespace.
Proposed Resolution:
Delete the Note.

In 8.6.6.3, AssociationEnd: values is not marked Properties: derived, but it is a derived relation per the text.  And the derivation expression is nonsense.  The text defines a recursive operation.
Proposed Resolution:
  Insert Properties: derived
  Delete the Tagged Value derivation, and state that the derivation is a recursive operation.

In 8.11.1 and 8.11.3, the entity-has-attributes association depicted in Figure 12 is not properly documented.  8.11.1 does not document .owning-entity.  In 8.11.3.3. .attributes does not show the parent association, and the parent association (entity-has-attributes) is not documented as an Association in 8.11.  
Proposed Resolution:
  Document the association in a new subclause of 8.11 and correct the corresponding elements of 8.11.1 and 8.11.3.

In 8.11.1.3, AssociationEnd: of-entity, the text of the Note defines an unmodeled (derived) association that subsets the TypeElement.namespace association for Attribute.  And the /owning-entity association end depicted in Figure 12 is not that association, since the inverse relationship defined in 8.11.3.3 (EntityType::attributes) includes the attributes of subtypes.  
As a consequence, the association that defines the namespace/scope of the Attribute as a TypeElement is not actually modeled.
Proposed Resolution:
Model the derived association: :of-entity->declared-in as ":namespace" explicitly in Figure 12 and in 8.11.1.3, and show it as subsets TypeElement:namespace.

In 8.11.3.3 and 8.12.6.2, AssociationEnd: plays-domain-role
The derivation expression makes no sense.  What is being defined here is a set of instances that are individually related by a derived path from a member of self->attributes.
Proposed Resolution:
Remove the Tagged value derivation and describe the operation that produces the derived result.

In 8.11.3.3 and 8.12.7.2, AssociationEnd: plays-range-role, In the derivation expression, ParameterType:explicit-role is not defined anywhere.  The intended association is modeled as EntityType:used-in (InvertibleAttribute) in the text and in Figure 14.
Proposed Resolution:
In the derivation expression, REPLACE:
    ParameterType:explicit-role
  with:
   used-in
(Note, however, that used-in is a set.)

In 8.12.4.3 AssocationEnds: lower-bound and upper-bound, the tagged value 'derivation' has no value expression.  And none can be provided, because the derivation is different for DomainRole and RangeRole.  
Proposed Resolution:
 Delete the Tagged Value 'derivation'.
 For lower-bound, break the Definition paragraph before "The lower-bound on the Domain role..."
 For upper-bound (where the break already exists), make the paragraph normative/definitive:  remove "Note: ".

In 8.12.6 and 8.12.7 entity-plays-domain/range-role, the <<derivedFrom>> dependencies do not appear in Figure 12.  It appears that this is just documentation of the derivation of the derived association, and it only documents one leg of the derivation path.  All the other cases just define 'derivation', or express it in text.

Proposed Resolution:
Delete 8.12.6.1 and 8.12.7.1

In 8.13.1.3, AssocationEnds: lower-bound, upper-bound, the tagged value 'derivation' has no value expression.  And the text does not make the derivation clear.  The intent is that, when the restricted-type is an AggregationType, the lower-/upper- bound is the lower-/upper-bound of that AggregationType.
Proposed Resolution:
In 8.13.1.3, Association End: lower-bound

a.  After the Definition paragraph, ADD a new paragraph:
	When the restricted-type is an AggregationType, the lower-bound SizeConstraint is the lower-bound of that AggregationType.

b.  DELETE the "Tagged Values" and "derivation =" paragraphs.

In 8.13.1.3, Association End: upper-bound

a.  After the Definition paragraph, ADD a new paragraph:
	When the restricted-type is an AggregationType, the upper-bound SizeConstraint is the upper-bound of that AggregationType.

b.  DELETE the "Tagged Values" and "derivation =" paragraphs.

In 8.14, Figure 16, the Association Instance-of-type is not documented.  And it is not identified as the abstraction of the of-type associations in Clause 9.  It should not appear in the figure.
Proposed Resolution:
In Figure 16, DELETE the Instance-of-type association.

In 8.13.1.3, AssocationEnd refined-role, the tagged value 'derivation' has no value expression.  And the text makes the derivation clear.
Proposed Resolution:
In 8.13.1.3, AssocationEnd refined-role, DELETE the Tagged Values and derivation = paragraphs.

In 9.2.3.3 and 9.2.8.1, AssociationEnd: of-type
In 9.2.3.3 the value expression for 'derivation' is nonsense.  In 9.2.8.1, it is missing.  Following the text for the inverse relation described in 8.6.6.3, this is some kind of recursive derivation operation that should be described as an operation.

In 9.3, SimpleValues
Unlike all of the other abstract subtypes of Instance, SimpleValue has an of-type association and none of its subclasses have specific of-type associations.   This is because some SimpleValues can be values of more than one SimpleType.  Accordingly, each SimpleValue subclass should have a constraint on its of-type relationships:
  For LogicalValue: isIn(Core:BuiltinTypes:LOGICAL, self->of-type)
  For NumberValue: isIn(Core:BuiltinTypes:NUMBER, self->of-type)
  For RealValue: isIn(Core:BuiltinTypes:REAL, self->of-type)
  For IntegerValue: isIn(Core:BuiltinTypes:INTEGER, self->of-type)
  For StringValue: isIn(Core:BuiltinTypes:STRING, self->of-type)
  For BinaryValue: isIn(Core:BuiltinTypes:BINARY, self->of-type)

In 9.3, SimpleValues
There is no instance package that defines the simple values True, False and Unknown.  We cannot formally constrain BooleanValue to be True or False, since no Instance package defines those values.

Proposed Resolution:
Create an instance package in the Instances Package for the built-in LOGICAL constants TRUE, FALSE, UNKNOWN.

In 9.7.1.3, AssociationEnd: content
The text says it is derived, but Figure 25 shows it (correctly) as subsets member-values.
Modify the text to match the diagram.

In 9.7.4, extent-within-population
Population:extents is the composite association, not Extent:within-population. 
The attribute Population:extents is not documented in 9.7.2.3; it is documented as an inverse in 9.7.2.4, and 9.7.2.4 refers to Rules:Extent instead of Instances:Extent

In 10.4.11.3, GenericElement:source is documented as Properties: composite, but it is actually the (derived) ParameterType:contains association to the GenericElement that is the composite.  And Figure 29 shows neither as composite.  The text should be corrected, and the Figure should match.
The GenericElement occurs in the syntactic specification of the ParameterType for the specified Parameter.  It refers to the element of the type of the actual parameter that corresponds to that element of the type of the formal parameter.  Trying to model this in detail in MOF is just not practical.

In 12.3, the .id attribute of ConstantRef, ExtentRef, EnumItemRef, VariableRef, AttributeRef, GroupRef should all be documented as "subsets Expression.text" and not as derived from it.

In 12.3.5.3, Literal refers-to SimpleValue is not abstract.  There are no documented subtypes of Literal.  Should there be?

In 12.3.6.2 ParameterRef:id is inherited from VariableRef and should not appear here.

In 10.4.11.3, GenericElement:source is documented as Properties: composite, but it is actually the (derived) ParameterType:contains association to the GenericElement that is the composite.  And Figure 29 shows neither as composite.  The text should be corrected, and the Figure should match.
The GenericElement occurs in the syntactic specification of the ParameterType for the specified Parameter.  It refers to the element of the type of the actual parameter that corresponds to that element of the type of the formal parameter.  Trying to model this in detail in MOF is just not practical.

In 12.3, the .id attribute of ConstantRef, ExtentRef, EnumItemRef, VariableRef, AttributeRef, GroupRef should all be documented as "subsets Expression.text" and not as derived from it.

In 12.3.6.2 ParameterRef:id is inherited from VariableRef and should not appear here.

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

In 12.6 Operations and 12.7 Function Calls, the first two paragraphs of both sections are identical.  The first sentence reads: "This section describes Operations, QueryExpressions and Function Calls."  And then it goes on to describe them.  But 12.6 only presents the model for  Operations and 12.7 only presents the model for FunctionCalls.  These two paragraphs need to be rewritten in both places.

In 12.7.1 ActualParameter, there should be a Constraint that every ActualParameter is either inFunctionCall or inProcedureCall.  In the text, it is not clear what "(always in a FunctionCall)" means in "When the corresponding formal Parameter is an InParameter (always in a FunctionCall), …".  The intent is that in a FunctionCall, the corresponding formal parameter is always an InParameter, but the text appears to say that when the formal parameter is an InParameter it must be in a FunctionCall.  So the text should be clarified and a corresponding Constraint should be stated.

In 12.7.1.3, ActualParameter:actual-referent does not appear in Figure 38 above.  There should be a reference here to Figure 48.

In 12.8, Query expressions, first paragraph, "depicts the concepts" should be at least "Figure 38 depicts the concepts."  Further,  some of the text erroneously appearing at the beginning of 12.7 might belong here.  In EXPRESS, QUERY is a function.

In 12.9, AggregateInitializer, the result-value attribute should be documented as subsets Expression:evaluation, and not as derived from it.

In 12.9, AggregateInitializer, Figure 40, the use of ListMember is wrong.  A MemberBinding in an AggregateInitializer binds to a virtual "slot" in a virtual GenericAggregate.  It does not bind to a ListMember of a specific LISTValue until it is evaluated in a particular runtime occurrence.  (For example, the same initializer could produce different values if it occurs within a REPEAT statement and some member-value expression depends on the control-variable.)  So the model in Figure 40 is incorrect.  MemberBinding:to-slot is not a ListMember.   It is a GenericMember of "generic aggregate", which refers to the result of the AggregateInitializer itself.  In the metamodel, each other Expression class denotes the abstraction of its evaluation -- we don't explicitly model the result instance.  So GenericAggregate, if that is what it models, is not an Instance; it is the abstract result of the AggregateInitializer.  Each actual result value is an AggregateValue, but not necessarily a LISTValue.

In 12.10 PartialEntityConstructor, the id value attribute should be documented as subsets Expression.text, and not as derived from it.  And the result-value attribute should be documented as subsets: Expression.evaluation, and not as derived from it.

In 12.10 PartialEntityConstructor, Figure 41, the AttributeValue, SingleEntityValue, and PartialEntityValue objects are the result of evaluating the constructor at a particular runtime instant.  They should not be part of this model - the results of other operations are not modeled.  The associations that reflect runtime evaluation - AttributeBinding:to-value, and PartialEntityConstructor:result-value should be deleted from the model.  (Some such diagram could be used to explain what is happening, but it would be descriptive, not normative.  Or these relationships could be shown as some kind of stereotyped dependency.)

In 12.11 BuiltInConstants, the Indeterminate Literal ("?") appears in the diagram in Figure 42, but is not documented in the text.

In 12.11, each literal is said to represent some value.  But none of these values, except for Indeterminate, is actually specified as an Instance object in the Instances package (Clause 9).  Each of them should have a .refers-to link to an object that appears in Clause 9.  And each of these objects should have a .text attribute value, specifying its representation.

In 13.2.5.1, under AssociationEnd: in-block, the Note says that every statement that is not a StatementBlock occurs in a StatementBlock.  But the model does not appear to support this.  There is no such OCL rule.  And, for example, the end class of IFStatement:then-actions is a Statement, not a StatementBlock.  So the first sentence of the Note appears to be false and should be struck.  (Or the corresponding OCL rule should be written.)

In 13.3.1, AliasStatement, the text says the ALIAS statement binds the AliasVariable to a VARExpression called the "referent", but neither the diagram nor the documented associations relate a VARExpression to the AliasStatement.  13.3.2 shows the referent VARExpression as an attribute of AliasVariable.  This association should certainly appear in the diagram in Figure 44.  But the actual referent of the AliasVariable at any given time is what the VARExpression evaluates to when the AliasStatement is executed.  The referent VARExpression should be associated with the AliasStatement, not with the AliasVariable.  That other Variables have runtime values is a fact that does not seem to have an image in the metamodel (e.g., Variable does not have a current-value association); so the fact that an AliasVariable has a runtime referent should not have such a model, either.

In 13.3.3, Alias-binds-variable, it is the alias-variable property of the AliasStatement that is composite, not the namespace property of the AliasVariable, and Figure 44 shows neither.  This error is duplicated in 13.3.2.3 and 13.3.1.3.

In, 13.9.1.3 RETURNStatement:return-value, what is stated here for FunctionCalls is syntactically correct, but semantically incorrect.  The semantic rule is, if the RETURN statement appears in a FUNCTION it always has a return-value.  If the return-value is not specified in the syntax, it is (implicitly) a VariableRef to the FunctionResult.

In 13.10.4 AliasVariable, it should be stated that an AliasRef to an AliasVariable produces a different result from a VariableRef to an AliasVariable.  The AliasRef produces the cell/variable/referent place, the VariableRef produces the value that is currently there.   And for that reason, .refers-to may be a bad choice for the association end name (it is different from VariableRef:refers-to).

It seems an odd thing to me to create a subclass of ExplicitAttribute to 
instantiate for Attributes that have the potential to have inverses. I don't 
understand the rationale. Seems like it would be simper to have a constraint 
on InverseAttribute about it being owned by an EntityType referenced in an 
ExplicitAttribute

Figure 28 is a duplicate of Figure 29.  It does not depict the ActualType and its subtypes concepts that were in Figure 28 of the Alpha version of the specification.

In clause 8.11.1.3, the Definition of attribute-type says "represents the required DataType... The DataType is required to be ...".
What is intended here is "data type" -- the general concept -- not DataType, which is a class in the metamodel, and it is the wrong one.


Also, the second sentence could be less cryptic.  When the Attribute is defined within the scope of an Algorithm, the attribute-type can be an ActualType.  When the Attribute is an "abstract attribute", it's nominal attribute-type is always a GeneralizedType.

In clause 8.12.2.3, the Definition of range ends "Derivation: range = .domain-view.attribute-type."  This text should be struck.  The correct derivation is given below.

In clause 8.6, the 6th paragraph begins: "InstantiableTypes represent all of the data types that have actual Instances."  This is incorrect, since PartialEntityValues are instances of PartialEntityTypes, which are DataTypes but not InstantiableTypes.  Clause 8.6.7 correctly says that InstantiableTypes cover the data types of all objects and property values.


In clause 8.6.7, the second sentence of the definition reads: "InstantiableType is a proper subtype of DataType (which includes classifiers that represent conformance rules for InstantiableTypes)." The parenthetical clause is wrong or at least misleading, and in any case the intent here was probably to mention PartialEntityTypes.


The text of these two paragraphs should be corrected.

In clause 8.13.1.3 under lower-bound, the Definition reads:
"represents a restriction on the minimum cardinality of the role that is stated by the Redeclaration."  And upper-bound is similarly defined. But the lower-bound represents the minimum cardinality, which is a restriction on the cardinality.  It should be reworded: "represents the minimum cardinality of the role that is constrained by the Redeclaration."  And similarly for upper-bound.

In clause 12.3.2.3 EnumerationItem:refers-to says that it specializes Expression:evaluation.  In clause 12.3.4.3 IndeterminateRef:refers-to says that it specializes Expression:evaluation.  In clause 12.3.5.3 Literal:refers-to says that it specializes Expression:evaluation.


These should be documented as "subsets: Expression:evaluation" instead of being derived from it.

In clause 8.8.1.3 BinaryType:binary-length-constraint says that it refines InstantiableType.constraints.  In clause 8.8.7.3 StringType:string-length-constraint says that it refines InstantiableType.constraints.  In clause 8.9.1.3 AggregationType:lower-bound and :upper-bound say that they refine. InstantiableType.constraints.


Actually, they all subset ParameterType:constraints and should be documented as such.

In clause 8.4.7.3, at the end of the Definition of AssociationEnd: interfaced-elements, delete the text ".interfaced-elements=.interfaces.refers-to" It is the derivation below.


In clause 8.4.18.1, at the end of the Definition of AssociationEnd: interfaced-elements, delete the text ".interfaced-elements=.interfaces.refers-to" It is the derivation below.


In clause 8.4.18.1, at the end of the Definition of AssociationEnd: referenced-in, delete the text ".referenced-in=.referenced-as.interfacing-schema" It is the derivation below.

In many places, the specification uses the EXPRESS convention for qualified names (owner.element) instead of the UML convention (owner:element).  These should be changed to use the UML convention

The UML class diagrams were drawn with two different tools, with the consequence that the diagrams have two radically different styles.  This causes the reader to wonder whether there is a meaning to the difference in style.  Change all the class diagrams to use the same style

All of the Figure references in the Beta-1 text are broken.  They have been replaced by the section number in which the Figure is to be found.  And in most cases, the reference immediately precedes the figure in that section.  For example, on p.37, the second line of the first paragraph of section 8.5 (Remarks) reads: "8.5 depicts the Remark concept...".  In the Alpha version it read: "Figure 5 depicts the Remark concept...".


There are two other Figure reference errors: In 12.8, the reference is missing entirely; the second sentence begins "depicts...".  In 10.5, paragraph 1, "yyy" should be a reference to Figure 30.

The introductory text of sections 12.4 and 12.5 is identical, but section 12.4 is about indexing operations, and 12.5 is about selectors.  This should be cleaned up

In clause 8.6.7.3, InstantiableType:fundamental-type has multiplicity 1..1.  This is semantically correct, but it has the effect of requiring the fundamental-type association to be instantiated for every InstantiableType in every Schema, even though it is only used in evaluating Expressions involving SpecializedTypes.  The EXPRESS rule is given in the Definition, and it can be considered to be a (recursive) derivation rule.  Making the attribute "derived" in this way removes the requirement for it to be instantiated.


Proposed change:  Make InstantiableType:fundamental-type a derived association.