[Fwd: Part 28 -> Part 11 issue]

[Ed Barkmeyer]

Karl Brandt (PDTEC) cites the following EXPRESS schema text from AIC 105:

  FUNCTION ypr_index(ypr : ypr_enumeration) : INTEGER;
   CASE ypr OF
    yaw : RETURN (1);
    pitch : RETURN (2);
    roll : RETURN (3);
   END_CASE;
   RETURN (?);
  END_FUNCTION;  -- 10303-105: kinematic_structure_schema

  TYPE ypr_enumeration = ENUMERATION OF
       (yaw,pitch,roll);
  END_TYPE;  -- 10303-105: kinematic_structure_schema

  TYPE ypr_rotation = ARRAY[ypr_index(yaw):ypr_index(roll)] OF
        plane_angle_measure;
  END_TYPE;  -- 10303-105: kinematic_structure_schema

The problem is:  What does Part 11 require the parser to support?

Part 11 treats the bounds on aggregation types as "constraints".  So if the 
expression is too complex for the parser to evaluate at compile time, the parser 
can defer the evaluation to "run time", and unless the parser claims level 4 
conformance, it is not required to check that the "constraint is satisfied" at all.

It is part of the notion of an ARRAY, however, that the bounds are part of the 
characterization of its structure -- they determine the behavior of the indexing 
(subscript) function -- and not just constraints on its size.  If the parser is 
unable to evaluate the bound functions, it is then unable to determine whether a 
given subscript is valid, or what array element it refers to!

Is it acceptable for the parser to treat the ARRAY as LIST [0:?] OF base-type if 
the bound expressions are too complex for it to evaluate?

Note that in the case above, the evaluation of the bounds is intuitively 
obvious, but the expressions in fact contain FUNCTION invocations.  That 
implicitly renders them "maximally complex expressions", unless the parser is 
somehow clever enough to divide schema-defined FUNCTIONs into "can be evaluated 
at compile-time" and "might be possible to evaluate at run time".

In the Part 28 case, the effect of treating
   ARRAY[ypr_index(yaw):ypr_index(roll)] OF plane_angle_measure
as
   LIST [0:?] OF plane_angle_measure
is:
  - to lose the (fixed) array size information from the XML schema;
  - in some cases, to require the XML data to contain the size information that 
should have been known at compile-time and specified in the schema.
  - to create the possibility for the post-processor that an element that says 
it is an "array" (cType="array") in the schema doesn't have its size (arraySize) 
given in the schema.

But for the Part 28 team, the question here is:
  What does Part 11 require the parser to support?
So we can determine:
  What should Part 28 require the conforming pre-processor to do with an EXPRESS 
construct like this one?

-Ed

P.S. My personal preference would be to define an EXPRESS built-in function that 
converts ENUMERATION values to INTEGER by returning the ordinal value that 
corresponds to the position of the enumeration item in the enumeration list. 
This, and a number of "functions" that "convert" between aggregation-types would 
have been useful additions to EXPRESS v2, for just such reasons as this case. 
The EXPRESS tool should not be required to "know" about certain such functions 
in Part 4x, nor should it be required to puzzle out the effect of arbitrary 
sequences of code that do nothing more than cast/coerce the value to a different 
EXPRESS data type, such as the ypr_index function above.

But that appears to be water over the dam.
So what sandbag structure should we build downstream?

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

"The opinions expressed above do not reflect consensus of NIST,
  and have not been reviewed by any Government authority."