[wg11] Two more SEDS for Part 11

[Ed Barkmeyer]

In the EXPRESS metamodel project, whilst attempting to correct the model of 
GeneralizedType, the attached two (sets of) problems with the text of Part 11 
were discovered.

All but one of these problems are editorial.  Resolving the last issue with 
9.5.3.4 may require technical change, or a different editorial correction.

-Ed Barkmeyer

-- 
Edward J. Barkmeyer                        Email: edbark at nist.gov
National Institute of Standards & Technology
Manufacturing Systems Integration Division
100 Bureau Drive, Stop 8263                Tel: +1 301-975-3528
Gaithersburg, MD 20899-8263                FAX: +1 301-975-4482

-------------- next part --------------
Section 1.  GENERAL INFORMATION (completed by SC4 Secretariat/WG Convener):

SEDS Report Number: (EJB-9.5.3)
Date Submitted: 2006-01-17
Status:
Assigned WG:
SEDS Team Leader: 
SEDS Team Members: 


Section 2.  ENHANCEMENT AND DISCREPANCY INFORMATION (completed by Author of SEDS Report):

Author: Ed Barkmeyer, NIST
Email Address: edbark at nist.gov
Part and Clause where Issue Originates: Part 11, clause 9.5.3
Other Parts Affected by the Issue: none
Related Issues:
Summary/Abstract/Keywords: 
  generalized data type definition, AGGREGATE type definition


Problem Description:

Part 11 (2004), clause 9.5.3 says:
"The generalized data types (...) are used to allow generalization of the data types used to represent the formal parameters of functions and procedures."

This statement is ambiguous.  It doesn't say what GeneralizedTypes *are*, it says what they are *used for*.  And "generalization of the data types used to represent the formal parameters" is confusing.  What is meant is "data types *for* formal parameters that allow generalization of the *actual* parameter data types."

And clause 9.5.3.1, first sentence, says:
"An AGGREGATE data type is a generalization of all aggregation data types."

This is incorrect.  Correct is:
"An AGGREGATE data type is a generalization of all aggregation data types that have the same element type."


Conditions Under Which the Issue Was Discovered:
  Attempting to develop a formal metamodel for the EXPRESS language.  The relationship of the "generalized data type" concept to the "instantiable data type" concept was not initially clear.  It seems clear now that it is a "generalization/specialization" relationship comparable to that of a SELECT type to the types in its select-list.


Proposed Solution (Optional):

a.  In clause 9.5.3, replace the first sentence of the paragraph following the Example with:
"The generalized data types (AGGREGATE, the general aggregation data types, GENERIC, and GENERIC_ENTITY) (see 8.5) are generalizations of instantiable data types.  They are used as the data types of formal parameters of functions and procedures to allow generalization of the data types of the corresponding actual parameters in an invocation (see 12.8)."

b.  In clause 9.5.3.1, at the end of the first sentence add:
"that have the same element type"

(c. In some future edition, move all of the text of 9.5.3 following the Example, together with the text of all its subclauses, to 8.5.  9.5.3 is titled "Parameters", but 90% of the text is the specification of Generalized Data Types, which is the title of 8.5.)


Section 3.  RESPONSE INFORMATION (completed by SEDS Resolution Team Leader):


If Accepted, Resolution:


Section 4.  FOLLOW-UP INFORMATION (completed by WG Convener):

Class:
Priority:
Impact of Change: 
Further Action Required:
Action Required by SEDS Coordinator/WG Conveners/QC/SC4:



-------------- next part --------------
Section 1.  GENERAL INFORMATION (completed by SC4 Secretariat/WG Convener):

SEDS Report Number: (EJB-9.5.3.4)
Date Submitted: 2006-01-17
Status:
Assigned WG:
SEDS Team Leader: 
SEDS Team Members: 


Section 2.  ENHANCEMENT AND DISCREPANCY INFORMATION (completed by Author of SEDS Report):

Author: Ed Barkmeyer, NIST
Email Address: edbark at nist.gov
Part and Clause where Issue Originates: Part 11, clause 9.5.3.4
Other Parts Affected by the Issue: none
Related Issues:
Summary/Abstract/Keywords: 
  type_label, function return type


Problem Description:

Part 11 (2004), clause 9.5.3.4 says:
"b) The parameters passed to a function or procedure which use a reference to a type label shall be compatible with the data type of the parameter passed that declares the type label.

"c) The data types of local variables and return types of functions that refer via a type label to a parameter data type shall be identical to the parameter data type that declares the type label."

Both of these rules are inaccurate -- they confuse the roles of the formal parameter and actual parameter in the interpretation of type labels.

For rule (b):  The passed parameter does not declare the type label; it is the corresponding formal parameter that declares the type label.  The text should read:
"shall be compatible with the data type of the parameter passed 
> to the formal parameter <
that declares the type label"

For rule (c):  The "parameter data type that declares the type label" is a generalized data type.  So the text requires the instantiated return value to be an instance of a generalized data type, not an instantiable data type.  This is clearly not what was intended.  What was intended is: 
"shall be identical to the data type of the (actual) parameter passed to the formal parameter that declares the type label".

Further problem -- the data type of the actual parameter is not well-defined in all cases.  While rule (b) only requires data type compatibility, rule (c) interprets the type_label as a dynamic declaration of the data type of the return value or the local variables.  What is meant by "identical to the data type of the actual parameter" is not clear, but it would seem to require that "THE data type of the actual parameter" is well-defined.  The problem is that a value/instance in EXPRESS may simultaneously instantiate more than one data type.

Case 1:

  FUNCTION test(sample:GENERIC_ENTITY:k): BOOLEAN;
  LOCAL
    test_var: GENERIC_ENTITY:k;
  END_LOCAL;
  ...
  END_FUNCTION:

If some "sample" is a Multileaf entity instance, i.e. an entity instance that is an instance of A ANDOR B, what is the data type of test_var?
To be "identical", the data type of test_var must be all of the data types present in the "sample" instance, which are in fact not characterized by any entity data type declared in the schema.

Case 2:

  TYPE length_measure = REAL; END_TYPE;
  TYPE volume_measure = REAL; END_TYPE;
  TYPE measure = SELECT (length_measure, volume_measure); END_TYPE;
  ENTITY quantity;
    unit: STRING;
    base_quantity: measure;
  END_ENTITY;

  FUNCTION normalize(input:GENERIC:a): GENERIC:a;
  ...
  END_FUNCTION;

If normalize(q.base_quantity) is called for a base_quantity that is a length_measure value, is the return type measure or length_measure?  The declared data type of the actual parameter is measure, but the actual data type of the parameter is length_measure.


Conditions Under Which the Issue Was Discovered:
  Attempting to develop a formal metamodel for the EXPRESS language.  The proper interpretation of a type_label on a local variable or return type is not at all clear.


Proposed Solution (Optional):

In 9.5.3.4, modify rule (b) to read:
"b) The parameters passed to a function or procedure which use a reference to a type label shall be compatible with the data type of the parameter passed to the formal parameter that declares the type label."

In 9.5.3.4, modify rule (c) to read:
"c) The data types of local variables and return types of functions that refer via a type label to a parameter data type shall be identical to the data type of the (actual) parameter passed to the formal parameter that declares the type label."

(No solution to the "further problem" of type ambiguity is proposed.)


Section 3.  RESPONSE INFORMATION (completed by SEDS Resolution Team Leader):


If Accepted, Resolution:


Section 4.  FOLLOW-UP INFORMATION (completed by WG Convener):

Class:
Priority:
Impact of Change: 
Further Action Required:
Action Required by SEDS Coordinator/WG Conveners/QC/SC4: