QUERY 'pipe' character makes simple debugging impossible

[ronaldtse]

From @TRThurman

I wrote this pseudocode quite a while ago in an effort to wrap my mind around the QUERY function as used
in STEP.

As noted, I don't know the proper computer science terminology here but from the perspective of the
language user, it takes 20 minutes or so to 'grok' EXPRESS-G and some time more.. a few weeks to become
comfortable with lexical EXPRESS and forever to be able to deal with the complexity that some of the APs
created for EXPRESS rules.

Don't get me wrong. I do understand the lingo.

The problem is that the pipe character makes simple debugging impossible.

For all recent work, I just use simple function calls and CASE statements to avoid this mess.

This human-interface language design issue should be one of the things addressed in an EXPRESS-2.

I don't really know enough about computer science to state the problem in a form that makes sense.
but the engineer in me sees the syntax of the logical expression and wants to make it a sub-routine.
the problem with that is that the pipe character "interferes" with easily decomposing the QUERY.

At one point I wrote some pseudo-code to keep track of the required forms for an important global rule in AP210.

5.2.4.306 shape_representation_requires_origin
NOTE This rule may not have been updated to agree with the changes in clause 4.2.
The shape_representation_requires_origin rule assures that each instance of shape_representation has exactly
one associated axis2_placement_2d or axis2_placement_3d with a name of ’origin’ or ’orientation’
or assures that the representation contains at least one styled_item or assures that the representation that
has a name of ’zone shape’ does not include an origin or orientation.

EXPRESS specification:

*)
RULE shape_representation_requires_origin FOR (shape_representation);
WHERE

WR1:
(*
pseudocode
co:FOREACH (sr <* shape_representation |c1);

c1:EXACTLYONE(it <* sr\representation.items |c2)
or ATLEASTONE(it <* sr\representation.items |c3)
or EXACTLYNONE(it <* sr\representation.items |c4);

c2:((it.name = ’origin’) or (it.name = ’orientation’)) and
(AXIS2_PLACEMENT_2D in TYPEOF(it) OR
AXIS2_PLACEMENT_3D in TYPEOF(it));

c3:STYLED_ITEM in TYPEOF(it);

c4:((it.name = ’origin’) or (it.name = ’orientation’)) and
((sr.name = ’zone shape’) or (sr.context_of_items.context_type = ’connection zone colour’));
*)
---------------------
SIZEOF(QUERY ( sr <* shape_representation | NOT(
(SIZEOF(QUERY ( it <* sr\representation.items | (
((it\representation_item.name = ’origin’) or (it\representation_item.name = ’orientation’))
((’ELECTRONIC_ASSEMBLY_INTERCONNECT_AND_PACKAGING_DESIGN.’ +
’AXIS2_PLACEMENT_2D’ in TYPEOF(it)) OR
(’ELECTRONIC_ASSEMBLY_INTERCONNECT_AND_PACKAGING_DESIGN.’ +
’AXIS2_PLACEMENT_2D’ in TYPEOF(it)))
))) = 1
)
OR
(SIZEOF(QUERY ( it <* sr\representation.items | (
(’ELECTRONIC_ASSEMBLY_INTERCONNECT_AND_PACKAGING_DESIGN.’ +
’STYLED_ITEM’ in TYPEOF(it))
))) >= 1
)
OR
(SIZEOF(QUERY ( it <* sr\representation.items | (
((it\representation_item.name = ’origin’) or (it\representation_item.name = ’orientation’))
((sr\representation.name = ’zone shape’) or
(sr.context_of_items\representation_context.context_type = ’connection zone colour’))
))) = 0
)
))) = 0;
END_RULE; -- shape_representation_requires_origin
(*
3984

Formal propositions:
WR1: For each instance of shape_representation, there shall be exactly one instance of placement in the
role of items that contains the attribute value ’origin’ for the name of that axis_placement or there shall
be at least one instance of placement in the role of items that contains the attribute value ’orientation’ for
the name of that axis_placement or ther shall be at least one instance of styled_item in the role of items.
The instance of placement shall be either an axis2_placement_2d or an axis2_placement_3d. There shall
be no instance of placement with name of origin or orientation in a shape_representation with a name of
’zone shape’ or with a context type of ’connection zone colour’.

Here is an example where I didn't bother with pseudo code. (should have)

ENTITY product_specific_parameter_value_assignment
SUBTYPE OF (product_related_characterized_product_category);
WHERE
...
WR2: SIZEOF(QUERY(pd <* USEDIN(SELF,
’ELECTRONIC_ASSEMBLY_INTERCONNECT_AND_PACKAGING_DESIGN.’ +
’PROPERTY_DEFINITION.DEFINITION’) |
(pd\property_definition.description =
’product category parameter’) AND
(SIZEOF(QUERY(pdr <* USEDIN(pd,
’ELECTRONIC_ASSEMBLY_INTERCONNECT_AND_PACKAGING_DESIGN.’ +
’PROPERTY_DEFINITION_REPRESENTATION.DEFINITION’) |
(SIZEOF ([’ELECTRONIC_ASSEMBLY_INTERCONNECT_AND_PACKAGING_DESIGN.’ +
’MODEL_PARAMETER’,
’ELECTRONIC_ASSEMBLY_INTERCONNECT_AND_PACKAGING_DESIGN.’ +
’MEASURE_REPRESENTATION_ITEM’,
’ELECTRONIC_ASSEMBLY_INTERCONNECT_AND_PACKAGING_DESIGN.’ +
’DESCRIPTIVE_REPRESENTATION_ITEM’] *
TYPEOF (pdr.used_representation)) = 1))) = 1))) = 1;

WR2: It shall be the definition of exactly one property_definition with a description of ’product category
parameter’ that is the definition of a property_definition_representation with a used_representation that is
a representation that has in its items exactly one model_parameter, exactly one measure_representation_item, or exactly one descriptive_representation_item.

So the engineer would like to do something like this:

#1=product_specific_parameter_value_assignment
#2=PROPERTY_DEFINITION('',#1,’product category parameter'..)
#3=PROPERTY_DEFINITION_REPRESENTATION('',#2,#4)
#4=REPRESENTATION((#5|#6|#7))<<<<NEW SYNTAX TO ACCOUNT for alternatives
#5=MODEL_PARAMETER
#6=MEASURE_REPRESENTATION_ITEM
#7=DESCRIPTIVE_REPRESENTATON_ITEM

Note that the rule as written is wrong anyway because it claims that the rep_items are representations.
The rule is from an early edition of AP210.

We resolved that problem by moving most of the rules from the AIM to the ARM,

Here is the ARM:

ENTITY Product_specific_parameter_value_assignment;
 of_product         : Product;
 assigned_parameter : Parameter_assignment;
DERIVE
 the_model_parameter : Model_parameter := assigned_parameter\Property_definition_representation.definition;
UNIQUE
 UR1: the_model_parameter, of_product;
END_ENTITY;

A challenging issue for users of EXPRESS is the concrete syntax for QUERY.

The QUERY syntax has a vertical pipe character that makes is difficult/tedious to decompose a complex rule (which may contain several QUERY).

Just wondering if we could come up with a dot language output for a QUERY that doesn't resolve completely?

Because logical_expression is widely used where it contains further QUERY declarations the QUERY declarations would be nodes.