[wg11] SEDS for Part 11 (v2)

[Ed Barkmeyer]

Attached please find 5 SEDS for ISO 10303-11:2004.

I previously sent these to the WG11 exploder for review.
  seds11-9-2-1 (Part 11, clause 9.2.1, attributes) is unchanged.
  seds11-12-2-1 (actually 12.2.1.6, aggregate comparison) is unchanged.
  seds11-12-7-3 (editorial) is revised per WG11 recommendation.
  seds11-12-9r1 (aggregate initializer) is entirely rewritten per WG11 
recommendation.
  seds11-12-10 (entity constructors) is technically unchanged, but 
editorially significantly revised per WG11 discussion.

-Ed Barkmeyer

-- 
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.2.1.6
Other Parts Affected by the Issue: none
Related Issues:
Summary/Abstract/Keywords: 
  aggregate comparison

Problem Description:

The second paragraph of clause 12.2.1.6 (Aggregate comparisons) seems to provide a definition for comparison that renders the third paragraph contradictory.

The second paragraph reads:
"The aggregate comparisons compare the elements of the aggregate value using value comparisons. If any of the element comparisons evaluate to FALSE, the aggregate comparison evaluates to FALSE. If one or more of the element comparisons for a particular aggregate comparison evaluate to UNKNOWN and the remaining comparisons all evaluate to TRUE, the aggregate comparison evaluates to UNKNOWN. Otherwise the aggregate comparison evaluates to TRUE."

But the third paragraph defines "equal" for ARRAY, LIST, BAG and SET with an if and only if condition in each case.  The relationship between this and "evaluates to TRUE" or "evaluates to UNKNOWN" is not clear.  And BAG/SET comparisons are defined in terms of VALUE_IN.  

Conditions Under Which the Issue Was Discovered:
  Trying to determine the rules for aggregate comparisons involving aggregate initializers (subject of a separate SEDS).

Proposed Solution (Optional):

Modify the second and following sentences of the second paragraph of 12.2.1.6 (cited above) to read:
"The aggregate comparisons compare the values of the elements of the aggregate value according to the aggregation data type, as specified below. If any of the specified element comparisons evaluate to FALSE, the aggregate values are "not equal". If all of the specified element comparisons evaluate to TRUE or UNKNOWN and at least one evaluates to UNKNOWN, the aggregate comparison evaluates to UNKNOWN.  If all of the specified element comparisons evaluate to TRUE, the aggregate values are "equal".

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 or declarations 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.9, 12.2.1.6
Other Parts Affected by the Issue: none
Related Issues:
Summary/Abstract/Keywords: 
  aggregate initializer

Problem Description:

The syntax of EXPRESS makes the aggregate initializer a simple-factor that can occur in arbitrary expressions.  The aggregate initializer is used widely in SC4 EXPRESS models, particularly in conjunction with the * operator (for example, in Part 41 clause 6.4.6, entity product_definition_shape) and with the value equality operator (=).  It is commonly assumed that an aggregate initializer can appear in any operation that takes an aggregate value as an operand, or as an actual parameter for any formal parameter whose data type is an aggregation data type. 

But Part 11 does not define any operation on the result of an aggregate initializer except assignment.

Clause 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 the value is created *for an assignment* only. The second sentence assumes that "the base data type of the aggregate" is known.  This is true for an assignment (the left operand has some base-type), and maybe for an actual parameter in a function call, but nowhere else.

According to clause 12.9, the aggregate initializer returns a value of type AGGREGATE OF GENERIC.  But AGGREGATE OF GENERIC is not an "instantiable data type".  And no operation in clause 12.2 or 12.6 is defined for a value of data type AGGREGATE OF GENERIC.  Indexing is defined for ARRAY, BAG, LIST and SET only (and differently for each).  Intersection, Difference, Subset and Superset operators are defined for BAG and SET only.  Union is defined only for BAG, SET and LIST.  QUERY might be defined, depending on the interpretation of rule (b).  In 12.2.3, IN might be defined, but it can only evaluate to TRUE if agg[i] is defined, and indexing is not defined on AGGREGATE.  And an aggregate initializer 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.

So the aggregate initializer is syntactically permitted in a number of places, but except for assignment, no valid syntactic occurrence has a defined meaning!  In particular, the meaning of the Intersection (*) in Part 41 clause 6.4.6, and tests for equality in many other places, are completely undefined in 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.

Proposed Solution (Optional):
  
a. Replace the first paragraph of clause 12.9 with the following:

"An aggregate initializer is used to specify a value of an aggregation data type (ARRAY, BAG, LIST, or SET).  Square brackets enclose zero or more expressions which evaluate to the elements of the aggregate value.  When there are two or more such expressions, commas shall separate them.  The aggregate initializer expression evaluates to an aggregate value whose elements are the specified values.  

When the usage (see below) requires the aggregate value to be interpreted as a LIST, the ordering is the order of their occurrence in the aggregate initializer, from left (first) to right (last).  When the usage requires the aggregate value to be interpreted as an ARRAY, the leftmost element value is associated with the lowest index value, and the associations occur in order up to the rightmost element value, which is associated with the highest index value.

When the square brackets enclose zero expressions, the aggregate initializer specifies an aggregate value that has no elements, i.e. an empty set, bag or list.   

"NOTE  The indeterminate value (?) may be a valid value for an element of the aggregate value.  For example, the aggregate value may be assigned to an attribute of whose data type is an ARRAY OF OPTIONAL."

b. After the second example (i.e. at the end of the clause), add the following normative text: 

"There are three cases in which an aggregate initializer may appear:
 -- as the right operand of an assignment
 -- as an actual parameter in a function call
 -- as an operand of a binary operation
The interpretation of the aggregate initializer is somewhat different in each of these cases.

"12.9.1 Aggregate initializer as assignment operand

When the aggregate initializer appears as the right operand expression of an assignment statement (see 13.3), the aggregate initializer shall be interpreted as a value of the declared data type of the left operand.

When the aggregate initializer appears as the (entire) constant_body of a constant declaration (see 9.4), the aggregate initializer shall be interpreted as a value of the declared data type of the constant. 

When the aggregate initializer appears as the derivation expression for a derived attribute (see 9.2.1.2), the aggregate initializer shall be interpreted as a value of the declared data type of the attribute.

Rules and restrictions:

(a) Each element expression shall evaluate to a valid value of the base-type of the declared data type.  Exception: If the declared data type is an ARRAY OF OPTIONAL, an element expression may evaluate to indeterminate (?). 

(b) The number of elements in the specified aggregate value shall satisfy all constraints on the number of elements of a valid value of the declared data type.

(c) If the declared data type requires the element values to be unique, no two elements in the specified aggregate value shall be value-equal (see 12.2).

"12.9.2 Aggregate initializer as actual parameter

When the aggregate initializer appears as an actual parameter in a function call (see 12.8), the aggregate initializer shall be interpreted as a value of the declared data type of the corresponding formal parameter.

If the declared data type of the formal parameter is an instantiable data type, the "declared data type" for the aggregate initializer shall be the declared data type for the formal parameter and the rules in 12.9.1 shall apply.

If the declared data type of the formal parameter is a generalized data type that contains a reference tag, and the declared data type of some other formal parameter contains the same reference tag, then the declared data type for the specified aggregate value shall be derived from the declared data type for the actual parameter that corresponds to the other formal parameter, as specified in 9.5.?, and the rules in 12.9.1 shall apply.

NOTE  The reference tag requires the corresponding elements of the data types of the actual parameters corresponding to the two formal parameters to be the same.  So it is assumed that the data type of the specified aggregate value should match the data type of the other formal parameter.

In any other case, the aggregate initializer shall be an invalid actual parameter.

EXAMPLE
...

"12.9.3 Aggregate initializer as operand

When the aggregate initializer appears as an operand of a binary operation, the other operand shall not be an aggregate initializer.  

If the other operand is an aggregate value, the specified aggregate value shall be interpreted as a value of that kind of aggregation (ARRAY, BAG, LIST or SET) and the base-type of the specified aggregate value shall be taken to be the base-type of the other operand.

If the other operand is not an aggregate value, the specified aggregate value shall be interpreted as a BAG whose base-type is the data type of the other operand.

The specified aggregate operation shall be performed as specified for operands with the data types so determined.

Rules and restrictions:

(a) Each element expression shall evaluate to a valid value of the base-type for the aggregation initializer, determined as specified above.  Exception: If the base-type is OPTIONAL, an element expression may evaluate to indeterminate (?). 

(b) If the specified aggregate value is interpreted as an ARRAY, the number of elements in the specified aggregate value shall match the number of elements in the other operand.  In any other case, the number of elements in the specified aggregate value is not constrained.

EXAMPLE 1

In the expression:
  ["S.ELLIPSE","S.POLYGON"] * TypeOf(curve)
the aggregate initializer is interpreted as having data type SET OF STRING, because the result data type of TypeOf (see 15.25) is SET OF STRING.  And the intersection operation (*) is performed as defined for two SET operands.

EXAMPLE 2

Given:
  ENTITY snark;
    primary_index : INTEGER;
    multipliers: LIST [3:3] OF REAL := [1.0, 0.5] + primary_index;
  END_ENTITY;

The aggregate initializer [1.0, 0.5] is taken to be a BAG OF INTEGER because it is an operand of + and the other operand is an INTEGER.  As a consequence the element values 1.0 and 0.5 are invalid, and the assignment (BAG OF INTEGER to LIST OF REAL) is invalid.

This can be corrected by defining:
  FUNCTION append_real (seq: LIST OF REAL, item:REAL): LIST OF REAL;
    RETURN seq + item;
  END_FUNCTION;

  ENTITY snark;
    primary_index : INTEGER;
    multipliers: LIST [3:3] OF REAL := append_real([1.0, 0.5],primary_index);
  END_ENTITY;

As specified in 12.9.2, the aggregate initializer [1.0, 0.5] is an actual parameter that is taken to be a value of the formal parameter type LIST OF REAL."


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 the partial complex entity value that contains all of the single entity values 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, at most one single entity value shall correspond to any given entity declaration.

b) In the resulting partial complex entity value, all single entity values contained shall correspond to nodes of at least one valid subtype/supertype graph.  

Note: A partial complex entity value need not contain single entity values corresponding to all the entity declarations that are required for a given subtype/supertype graph. Further operations can add additional single entity values."


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 data type of the formal parameter 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.2.1.6) 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 effect 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 single entity values 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: