Create encoder of EXPRESS-G diagrams via GraphViz

[ronaldtse]

This is action_schemaexpg1.gif from STEPmod.

I've been able to reproduce this using this DOT syntax:

digraph {
  node[shape=record];
  ab[label="", fixedsize="false", width=0, height=0, shape=none];
  as[label="", fixedsize="false", width=0, height=0, shape=none];
  c[label="", fixedsize="false", width=0, height=0, shape=none];
  d[label="", fixedsize="false", width=0, height=0, shape=none];

  edge [dir=forward];
  splines=ortho;
  rankdir=LR;

  action_schema [label="action_schema|"];
  basic_attribute_schema [label="basic_attribute_schema|"];
  support_resource_schema [label="support_resource_schema|"];

  action_schema -> ab[arrowhead=None,style=dashed];
  ab -> basic_attribute_schema[style=dashed, arrowhead=odot];
  c -> ab [label="description_attribute\ldescription_attribute_select\lget_description_value\lget_id_value\lget_name_value\lid_attribute\lid_attribute_select\lname_attribute\lname_attribute_select\l"];

  action_schema -> as[arrowhead=None,style=dashed];
  as -> support_resource_schema[style=dashed, arrowhead=odot];
  d -> as [label="bag_to_set\lidentifier\llabel\ltext\l"];

  {rank=same; action_schema; ab; basic_attribute_schema, as, support_resource_schema};
}

[ronaldtse]

From Stuart:

STEPmod:

Re-created:

digraph {
  splines=ortho;
  rankdir=LR;

  node[shape=record];
  n0 [label="Analysis_shape_mim|"];
  p0 [shape=none, width=0, height=0, label=""];
  n1 [label="Analysis_identification_mim|"];
  n2 [label="Product_view_definition_mim|"];
  n3 [label="Shape_property_assignment_mim|"];

  edge [dir=forward, arrowhead=odot];
  n0 -> p0[dir=none];
  p0-> {n1; n2; n3}
}

[ronaldtse]

We will need to use the Expressir parse tree to generate the diagrams.

Further ideas:

We also need to define what input an "EXPRESS-G diagram generation from EXPRESS process” takes.

Annex D defines two types of diagrams, the “schema-level” and “entity-level” diagrams, and they can be partial or “complete”. Perhaps Tom can tell us whether this means that these are the only two detail levels we should care about? (both examples Stuart gave are schema-level diagrams)

For example, the first example demonstrates the USE relationship between three EXPRESS schemas. We can read the EXPRESS schemas and infer the relationships, but someone needs to define that only the “schema-level” object and relationships are shown.

I can’t seem to find an ASCII-defining language for EXPRESS-G diagrams, so I’m using an EXPRESS-like definition syntax below (we can also use general syntaxes like YAML/JSON),

e.g.

DIAGRAM Analysis_shape_arm_diagram;
  IMPORT Analysis_shape_arm;
  DETAIL_LEVEL ( schema );
END_DIAGRAM

In the second example,

DIAGRAM Associative_draughting_elements_mim_diagram;
  IMPORT Associative_draughting_elements_mim;
  DETAIL_LEVEL ( schema );
END_DIAGRAM

Both of these are “schema-level” diagrams.

An entity-level diagram looks like this:

generated from this schema:

SCHEMA Analysis_representation_arm;

USE FROM Foundation_representation_arm;

ENTITY Analysis_model
  SUBTYPE OF (Representation);
  SELF\Representation.context_of_items : Analysis_representation_context;
END_ENTITY;

ENTITY Analysis_representation_context
  SUBTYPE OF (Representation_context);
END_ENTITY;

END_SCHEMA;

The parser would need to understand that “Representation” and “Representation_context" entities come from the “Foundation_representation_arm" schema, and that means we also need to ignore all the other entities defined in Foundation_representation_arm.

DIAGRAM Analysis_representation_arm_diagram;
  IMPORT Analysis_representation_arm;
  DETAIL_LEVEL ( entity );
END_DIAGRAM

I guess we can say that if a schema is not IMPORTed, then we don’t draw it directly.

Perhaps this is still insufficient in defining a generic EXPRESS-G diagram? Any thoughts?

[TRThurman]

It is important to recognize as you do that a diagram is different from a schema. I proposed to move the DETAIL_LEVEL keyword up to just after the DIAGRAM keyword. see below for others. Tom

We will need to use the Expressir parse tree to generate the diagrams. Further ideas:

We also need to define what input an "EXPRESS-G diagram generation from EXPRESS process” takes.

Annex D defines two types of diagrams, the “schema-level” and “entity-level” diagrams, and they can be partial or “complete”. Perhaps Tom can tell us whether this means that these are the only two detail levels we should care about? (both examples Stuart gave are schema-level diagrams)

For example, the first example demonstrates the USE relationship between three EXPRESS schemas. We can read the EXPRESS schemas and infer the relationships, but someone needs to define that only the “schema-level” object and relationships are shown.

TT-It is safe to interpret Annex D as disallowing combined schema and entity diagrams.

Clause 6.8 of N3554 specializes Annex D for 10303.

I can’t seem to find an ASCII-defining language for EXPRESS-G diagrams, so I’m using an EXPRESS-like definition syntax below (we can also use general syntaxes like YAML/JSON),

e.g.

DIAGRAM Analysis_shape_arm_diagram; IMPORT Analysis_shape_arm; DETAIL_LEVEL ( schema ); END_DIAGRAM

In the second example,

DIAGRAM Associative_draughting_elements_mim_diagram; IMPORT Associative_draughting_elements_mim; DETAIL_LEVEL ( schema ); END_DIAGRAM

Both of these are “schema-level” diagrams.

An entity-level diagram looks like this:

DIAGRAM Analysis_representation_arm_diagram; IMPORT Analysis_representation_arm; DETAIL_LEVEL ( content ); END_DIAGRAM

generated from this schema:

SCHEMA Analysis_representation_arm;

USE FROM Foundation_representation_arm;

ENTITY Analysis_model SUBTYPE OF (Representation); SELF\Representation.context_of_items : Analysis_representation_context; END_ENTITY;

ENTITY Analysis_representation_context SUBTYPE OF (Representation_context); END_ENTITY;

END_SCHEMA;

The parser would need to understand that “Representation” and “Representation_context" entities come from the “Foundation_representation_arm" schema, and that means we also need to ignore all the other entities defined in Foundation_representation_arm.

Yes

DIAGRAM Analysis_representation_arm_diagram; IMPORT Analysis_representation_arm; DETAIL_LEVEL ( content );<<<<change term as other declarations are included in EXPRESS-G. END_DIAGRAM

I guess we can say that if a schema is not IMPORTed, then we don’t draw it directly. That seems to be the case which would allow this:

DIAGRAM part111_diagram; DETAIL_LEVEL ( schema ); IMPORT SCHEMA_1_arm; IMPORT schema_2_mim; ... IMPORT schema_N_mim; END_DIAGRAM

Perhaps this is still insufficient in defining a generic EXPRESS-G diagram? Any thoughts?

Looks pretty complete with the trivial mods I proposed.

[ronaldtse]

6.8 of N3554 is attached:

[TRThurman]

Our usual practice is to NOT omit the symbols for base types and identifier, label, text.