[wg11] SEDS for EXPRESS (10303-11:2004)

[Ed Barkmeyer]

All,

The attached four SEDS reports fell out of the (unofficial) project to 
develop a formal metamodel for the EXPRESS language.

All of these changes are expected to be Editorial, in that they correct 
or clarify inaccurate or ambiguous wording.  The proposed changes to 
clause 12.9 and clause 12.10, however, may not be the interpretation of 
the text that WG11 actually intended, and if that is the case, then 
these may become technical issues.

-Ed

P.S. I put these on the table now, because we just discovered them, and 
because I understand that there is a forthcoming TCorr to fix EXPRESS-G 
problems with EXPRESS edition 2.

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


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

SEDS Report Number:
Date Submitted:
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.2.1
Other Parts Affected by the Issue: none
Related Issues:
Summary/Abstract/Keywords: 
  explicit attribute, derived attribute, computation

Problem Description:

Clause 9.2.1 says:
"There are three kinds of attribute:
  Explicit: An attribute whose value shall be supplied by an implementation in order to create an entity instance.
  Derived: An attribute whose value is computed in some manner.
  Inverse: An attribute whose value consists of the entity instances which use the entity in a particular role."

a) Is it the intent that these three kinds of attribute are mutually exclusive?  Or are there "ANDOR" relationships?  Because an explicit attribute can be redeclared as DERIVEd in a subtype, it is apparently not the case that they are mutually exclusive.  

b) In 9.2.1.1, it is stated:
"The keyword OPTIONAL indicates that, in a given entity instance, the attribute need not have a value."
So for an explicit attribute that is OPTIONAL, a value "shall be supplied by an implementation" but the attribute "need not have a value"?
It follows that "whose value shall be supplied by an implementation" cannot be the *definition* of an explicit attribute.  (Or, by definition, an OPTIONAL attribute is NOT an explicit attribute.)  What is the definition?

c) In clause 1 it explicitly says that "information processing" is out of scope for Part 11.  How then can an explicit attribute be "an attribute whose value shall be supplied by an implementation in order to create an entity instance"?  Creating an entity instance is an information processing action.  In data, the entity instance either exists or it doesn't.  And "supplying data" is an SDAI kind of thing.  In data, there is either a value or no value.  

d) Similarly, a DERIVEd attribute is not an attribute whose value *is* computed in some manner.  Many entity instances and attribute values are computed in some manner, and all of that is out of scope.  Rather a derived attribute is an attribute whose value *can always be* computed from the values of other modeled attributes of the entity instance.

Conditions Under Which the Issue Was Discovered:
  Attempting to develop a formal metamodel for the EXPRESS language.  It is not possible to determine from Part 11:2004 how to model the relationships among the three "kinds" of attributes.  In particular, one of the participants interpreted the definition of 'derived attribute' as "whose value *shall not be provided* by an implementation"!

Proposed Solution (Optional):

1. Replace the three "definitions" in 9.2.1 with something like:
  "An explicit attribute represents a relationship that is considered to belong to the entity instance, and not to the related instance referenced by the attribute.
  "An inverse attribute represents the view from the entity of a relationship that is considered to belong to the (entity) data type referenced by the attribute.  Its value consists of the instances of the referenced data type that use the entity in a particular role.
  "A derived attribute represents a relationship that need not be explicitly represented in the instance because the related value can always be determined from the values of other modeled attributes by evaluating a particular expression."

[this text builds on the first paragraph of 9.2.1 and represents the intended distinctions.]

2.  Replace the first sentence of 9.2.1.1 with
  "An explicit attribute represents a relationship that is considered to belong to instances of the entity data type, and not to the related data type."
(whether a value is required is covered by Rules (a) and (b)).


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:
Date Submitted:
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 12.7.3
Other Parts Affected by the Issue: none
Related Issues:
Summary/Abstract/Keywords: 
  attribute, partial complex entity

Problem Description:
  In clause 12.7.3 (Attribute references), the following appears:
"If the expression to the left of the attribute reference evaluates to a partial complex entity value then the attribute name to the right of the attribute reference shall occur within the entity declaration for that partial complex entity data type."

But "that partial complex entity data type" may, in general, have more than one entity declaration.  3.3.14 defines "A partial complex entity data type is a grouping of entity data types within a subtype/supertype graph ...".  The intent in 12.7.3 is to refer to the output of the group operator, which has exactly one entity data type in the "grouping", but it is not clear that the left operand couldn't be (A(1) || B(2)), which (per 12.10) also produces a partial complex entity instance.

Conditions Under Which the Issue Was Discovered:
  Problem discovered while trying to make a metamodel of the concepts of the EXPRESS language.  

Proposed Solution (Optional):

Modify 12.7.3 to read:
"shall occur within the entity declaration(s) for that partial complex entity data type"


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:
Date Submitted:
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 12.10
Other Parts Affected by the Issue: none
Related Issues:
Summary/Abstract/Keywords: 
  complex entity constructor, partial complex entity value

Problem Description:
  As described in clause 12.10, the complex entity construction operator is not a binary operator and has no meaningful binary decomposition.  The binary operator does not "construct an entity instance".  The text of clause 12.10 is generally muddled.

1. "The complex entity instance construction operator (||) constructs an instance of a complex entity by combining the partial complex entity values."

The operator || constructs a partial complex entity value by combining TWO partial complex entity values.  It does not construct an entity instance, and in general what it constructs cannot be interpreted as an entity instance -- it is just some set of nodes in the type graph.

2. "The partial complex entity values may be combined in any order."

It is not clear what the sentence means for the binary operator.  The result of the binary operator is a set of groups of attribute values corresponding to entity declarations.  Per 3.3.14, the represented nodes are required to be somehow connected in the type graph, but it is not clear what kind of "ordering" anyone would have expected.

3. "A complex entity instance construction operator expression evaluates to either a partial complex entity value or a complex entity instance."

No.  It always evaluates to a partial complex entity value.
In some cases, a partial complex entity value can be interpreted as a reference to an entity instance, but that concern arises only in "assignment".

4. "A partial complex entity data type may only occur once within one level of an entity instance construction operator expression. A partial complex entity value may occur at different levels if these are nested, that is, if a partial complex entity value is being used to construct a complex entity instance which plays the role of an attribute within partial complex entity value being combined to form the complex entity instance."

This discussion interprets the || operator as n-ary, and apparently assumes that partial complex entity values can be nested.  Partial complex entity values are not "nested".  An expression that evaluates to a partial complex entity value and is used as the value of an attribute *is being assigned* and must be converted to an entity instance.  So a partial complex entity value can contain nested entity instance references, but *not* nested partial complex entity values.

Conditions Under Which the Issue Was Discovered:
  Problem discovered while trying to make a metamodel of the EXPRESS language concepts.  The intended model of partial complex entity values and operations is not clear from Part 11.

Proposed Solution (Optional):

Note:  These proposed changes assume that a partial complex entity value results from the implicit entity constructor, the group operator or the || operator, and is converted to an entity instance only when it is assigned.  That means there is a hidden "coercion" or "cast" operator that is invoked by the assignment.

1.  Replace the first paragraph of clause 12.10 with:

  "The complex entity instance construction operator (||) constructs a partial complex entity value by combining other partial complex entity values.  If either of the operands evaluates to indeterminate (?), the expression evaluates to indeterminate (?).  Otherwise, the expression evaluates to a partial complex entity value containing all of the attribute groups present in the two operands.

  "A partial complex entity value that represents a valid complex entity instance, as specified in Annex B, may be converted to an entity instance when assigned to a variable, parameter or attribute whose value is required to be an entity instance (see 12.13). 

Note: When a partial complex entity value is used as the value of an attribute (a parameter) in a partial complex entity constructor (see 9.2.6), it is converted to an entity instance."

2.  After the second normative paragraph of 12.10, before the example, add:

"Rules and restrictions:

a) In the resulting partial complex entity value, the attribute group corresponding to a given entity declaration shall occur at most once.  

b) In the resulting partial complex entity value, all entity declarations represented shall be part of at least one valid type graph.  

Note: A partial complex entity value need not contain attribute groups corresponding to all the entity declarations that are required for a given type graph. Further operations can add additional attribute groups."


3.  In clause 12.8 (Function calls), after the first paragraph, insert:

"The expression representing the value of the actual parameter shall be evaluated to a single value, or indeterminate (?), in order to apply the function.  The corresponding formal parameter shall represent that value in evaluating the function.  If the formal parameter data type requires the value to be an entity instance, and the actual parameter is a partial complex entity value, an entity instance corresponding to the actual parameter value shall be created (see 12.13) and the formal parameter shall represent that entity instance in evaluating the function."

4.  In clause 13.3.1, after the second sentence of the first paragraph, insert:
"If the expression to the right of the assignment statement is a partial complex entity value, a corresponding entity instance is created (see 12.13), and the assignment statement assigns a reference to that entity instance to the local variable or parameter."

5.  Add a new subclause somewhere (12.10.1 or 12.13 or 13.3.3)

"12.13 Entity instance creation

"A partial complex entity value can be an actual parameter to a function (see 12.8) or the right hand side of an assignment statement (see 13.3).  When a partial complex entity value is assigned to a constant, variable, parameter or attribute whose value is required to be an entity instance, a reference to a corresponding entity instance is created from the partial complex entity value.  The entity instance shall be an instance in the population that is value-equal (see 12.x) to the partial complex entity value.  If there is no such instance in the population, a corresponding instance is added to the population within the scope of the assignment.  If the scope of the assignment is the schema (e.g., the expression is the value of a constant), the instance is considered to exist for the purposes of all global rules.  If the scope of the assignment is a function call, the instance has no affect on the population outside of the function.  Exception: see 12.8.

"Rules and restrictions:

a) The partial complex entity value shall consist of a set of attribute groups that corresponds to the structure of a valid complex entity instance, as specified in Annex B.

b) The corresponding entity instance shall be assignment compatible (see 13.3.2) with data type of the constant, variable, parameter or attribute to which it is being assigned."



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:
Date Submitted:
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 12.9, 12.2.1.6
Other Parts Affected by the Issue: none
Related Issues:
Summary/Abstract/Keywords: 
  aggregate initializer

Problem Description:

It appears to be the case that an aggregate initializer expression is only permitted as the right hand operand of an assignment statement and possibly as the right-hand operand of IN.  Is this so?  

This is not clear from the syntax, which makes the aggregate initializer a simple-factor that can occur in arbitrary expressions.  

According to clause 12.9, the aggregate initializer returns a value of type AGGREGATE OF GENERIC.  12.9 itself suggests that the only use is as the right-hand operand of an assignment statement, viz.:
"An aggregate initializer is used to establish a value of type AGGREGATE OF GENERIC that may be assigned to an ARRAY, BAG, LIST or SET. Square brackets enclose zero or more expressions which evaluate to values of a data type compatible with the base data type of the aggregate."

The first sentence suggests that such an assignment is the only valid use of the value of type AGGREGATE OF GENERIC, and the second sentence further supports this by assuming that "the base data type of the aggregate" (the left operand of the assignment) is known.  If no other use is valid, this should be clarified by a "rule" in 12.9.

If this is not the intent, what other use is valid?  No other operation, except possibly IN, appears to be defined on the result data type AGGREGATE OF GENERIC.

No aggregation operator (12.6) supports an operand of type AGGREGATE OF GENERIC, because none of the tables specifies it as the possible data type of either of the operands.  And it cannot be the actual parameter to a function call, because 9.5.3.1 explicitly requires the actual parameter corresponding to a formal parameter of type AGGREGATE OF x to be an ARRAY, BAG, LIST or SET.  

Depending on the interpretation of 9.5.3.1, AGGREGATE OF GENERIC may or may not be type-compatible (12.11) with any other aggregation data type.  If it is not type-compatible with anything, no aggregate comparison operator (12.2.1.6) supports an operand of type AGGREGATE OF GENERIC.  If it is type-compatible with other aggregation data types, no aggregate comparison operator is well-defined.

The ambiguity in 9.5.3.1 is the statement:
"An AGGREGATE data type is a generalization of all aggregation data types."
which may or may not be interpreted:
"Every aggregation data type is a specialization of the AGGREGATE data type with the same base type."

If the latter interpretation is not what was intended, then AGGREGATE OF GENERIC is not type-compatible with anything but itself, per 12.11.

If the latter interpretation is correct, since it is similarly stated that GENERIC is the generalization of all data types, 9.2.7 would permit the interpretation:
"Every aggregation data type is a specialization of AGGREGATE OF GENERIC."
And in that case, AGGREGATE OF GENERIC is type-compatible with all aggregation data types per 12.11.  And in that case, one would expect the equality and inequality relations (12.2.1.6) to apply to an operand of data type AGGREGATE OF GENERIC.

But 12.11 doesn't say which of the two compatible data types is taken to be the reference data type for the operation.  And 12.2.1.6 specifies how to compare two ARRAY operands, or two LIST operands, or two operands of types SET and/or BAG, but it does not specify how to compare any operand to an AGGREGATE OF GENERIC.  So, if it is permissible to compare an aggregate value to AGGREGATE OF GENERIC, the behavior of the comparison is not specified by Part 11.

Conditions Under Which the Issue Was Discovered:
  Problem was discovered while trying to develop a formal metamodel for the EXPRESS language.  The aggregate initializer is the only EXPRESS operation that produces a value that is not of an instantiable data type.  If the aggregate initializer can only appear in assignments and IN operands, it is easier to create separate semantic operators (e.g. IN_List and aggregate_initializer_statement) than to make it a general form of expression.


Proposed Solution (Optional):
  
In clause 12.9, add the following:

"Rules and restrictions:

"a) An aggregate initializer shall only appear as the 'expression' in one of the following:
 - an assignment statement (see 13.3)
 - the constant_body of a constant declaration (see 9.4)
 - a derived attribute (see 9.2.1.2)

"b) The expression that contains the aggregate_initializer shall consist solely of the aggregate_initializer."

[A better solution would be to change 'expression' in the syntax of those three declarations to 'assigned_value', with the production:
  assigned_value ::= expression | aggregate_initializer  .
and remove the 'aggregate_initializer' choice from the production for 'simple_factor'.]


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: