[Fwd: Part 28 -> Part 11 issue]

[Wilson, Peter R]

Ed,

    I must be missing something here. It has always been possible to do this:
ENTITY ent;
  low : INTEGER;
  high : INTEGER;
  arr : ARRAY[low:high] OF INTEGER;
-- and similarly for the other aggregates
-- WHERE
-- wr1 : low <= high; -- may or may not be specified
END_ENTITY;

    The array bounds cannot be known until runtime as the depend on values in any particular instance. 

Peter W.

Dr Peter R. Wilson
Boeing Commercial Airplanes
PO Box 3707, MS 2R-97, Seattle, WA 98124-2207
Tel: (206) 544-0589, Fax: (206) 544-5889
Email: peter.r.wilson at boeing.com
--------------------------------
Any opinions expressed above are personal;
they shall not be construed as representative of any organisation.
--------------------------------
 

> -----Original Message-----
> From: Ed Barkmeyer [mailto:edbark at nist.gov] 
> Sent: Friday, March 12, 2004 12:06 PM
> To: SC4 WG11
> Subject: [Fwd: Part 28 -> Part 11 issue]
> 
> 
> 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."
> 
>