Support informal propositions

ronaldtse commented 3 years ago

In annotated-express/action-schema.exp there is this remark tag:

  ENTITY action;
    name : label;
    description : OPTIONAL text;
    chosen_method : action_method;
  DERIVE
    id : identifier := get_id_value(SELF);
  WHERE
    WR1: SIZEOF(USEDIN(SELF, 'BASIC_ATTRIBUTE_SCHEMA.' + 'ID_ATTRIBUTE.IDENTIFIED_ITEM')) <= 1;
  END_ENTITY;

(*"action.ip:IP1"

This is a dummy ip inserted for prototyping.

note that the e.g., arm.xml uses a special encoding of a WR name to indicate an IP.
We propose to define a type for consistency.
*)

This is an "informal proposition". The only documentation for "informal propositions" I found was in ISO-TC184-SC4_N3485_Supplementary_Directives "Rules for the structure and drafting of SC 4 standards for industrial data, edition 5":

And:

In this syntax, I worry that action.ip also means "attribute = ip" because the remark tag action.id is also used.

@TRThurman can you help confirm that this is the correct syntax for stating informal propositions? Or propose a better syntax?

ronaldtse commented 3 years ago

@zakjan please also help describe/document how to retrieve one informal proposition from an EXPRESS entity via API call. Thanks.

TRThurman commented 3 years ago

We shall use the domain_rule syntax with a special STEPmod interpretation of the id value of '"IP"

so:

(*"action.wr:IP1"
This is a dummy ip inserted for prototyping.
note that the e.g., arm.xml uses a special encoding of a WR name to indicate an IP.
*)

As we require domain rules to NOT begin with "IP", conflict is avoided.

This is already implemented in the existing publication pipeline in e.g., xxxschema.xml

example:

      <where label="WR1" expression="SELF.context_of_items\geometric_representation_context.coordinate_space_dimension = 3"/>
      <where label="WR2" expression="SIZEOF(QUERY(it &lt;* SELF.items | (SIZEOF(['AIC_CSG.CSG_SOLID',&#10;                                              'AIC_CSG.MAPPED_ITEM',&#10;                                              'AIC_CSG.AXIS2_PLACEMENT_3D',&#10;                                              'AIC_CSG.SOLID_REPLICA',&#10;                                              'AIC_CSG.REVOLVED_FACE_SOLID',&#10;                                              'AIC_CSG.EXTRUDED_FACE_SOLID'] * TYPEOF(it)) &lt;&gt; 1))) = 0"/>
      <where label="WR3" expression="SIZEOF(QUERY(mi &lt;* QUERY(it &lt;* SELF.items | ('AIC_CSG.MAPPED_ITEM' IN TYPEOF(it))) | NOT ('AIC_CSG.CSG_SHAPE_REPRESENTATION' IN TYPEOF(mi\mapped_item.mapping_source.mapped_representation)))) = 0"/>
      <where label="WR4" expression="SIZEOF(QUERY(sr &lt;* QUERY(it &lt;* SELF.items | ('AIC_CSG.SOLID_REPLICA' IN TYPEOF(it))) | (SIZEOF(['AIC_CSG.CSG_SOLID',&#10;                                              'AIC_CSG.REVOLVED_FACE_SOLID',&#10;                                              'AIC_CSG.EXTRUDED_FACE_SOLID'] * TYPEOF(sr\solid_replica.parent_solid)) = 0))) = 0"/>
      <where label="WR5" expression="SIZEOF(QUERY(it &lt;* SELF.items | NOT ('AIC_CSG.AXIS2_PLACEMENT_3D' IN TYPEOF(it)))) &gt; 0"/>
      <where label="IP1"/>
      <where label="IP2"/>

zakjan commented 3 years ago

@ronaldtse From the parser perspective, this can be considered as another type of remark, recognizable with a special remark tag syntax. How about to make it accessible as entity.informal_proposition_remarks?

ronaldtse commented 3 years ago

@zakjan Basically IPs are like "where rules" but they are not stated inside the EXPRESS code, but only available as annotations to the EXPRESS entity.

How does one obtain "where rule" annotations right now?

We should use a similar mechanism as shown by @TRThurman :

<where label="WR5" expression="SIZEOF(...)"/>
<where label="IP1"/>

i.e. EXPRESS Path of "action.wr:WR1" gives us this:

    WR1: SIZEOF(USEDIN(SELF, 'BASIC_ATTRIBUTE_SCHEMA.' + 'ID_ATTRIBUTE.IDENTIFIED_ITEM')) <= 1;

and this:

(*"action.wr:WR1"
Each *action* shall be the express_ref:[basic_attribute_schema.id_attribute.identified_item] ...
*)

EXPRESS Path of "action.ip:IP1" gives us an object that only contains an annotation:

(*"action.ip:IP1"
This is a dummy ip inserted for prototyping....
*)

How do we get "action.wr:WR1" right now?

path("action.wr:WR1") ?
entity.where.find("WR1")?
entity.where.first?

Then "action.ip:IP1" should be available via:

path("action.ip:IP1") ?
entity.ip.find("IP1") or entity.informal_propositions.find("IP1")?
entity.ip.first or entity.informal_propositions.first?

zakjan commented 3 years ago

Thanks, it's helpful to know that they are more like where rules.

Currently a where rule can be retrieved by id by:

schema.find("action.WR1")
entity.find("WR1")
entity.where.select(|x| x.id == "WR1")
entity.where.first

IPs can be supported in a similar way.

However, paths containing : are not supported yet by the parser. It's fairly simple to add them, if there is a spec, or at least complete informal rules to follow. It seems that path <id>.<child_type>:<child_id> is equivalent to <id>.<child_id>, is it right? Then I would only need to know the possible values for child_type (wr, ip, anything else?).

zakjan commented 3 years ago

Also, can the path be nested like <id>.<child_type>:<child_id>.<child2_type>:<child2_id>?

ronaldtse commented 3 years ago

Currently a where rule can be retrieved by id by ...

Excellent.

I have to add that ISO 10303-11, 7.1.6.1 does not acknowledge the syntax with : (colon):

(@TRThurman can you confirm the syntax <type>:<id> is desired and acceptable from the viewpoint of ISO 10303?)

I think we can enumerate type in <type>:<id> syntax according to Clause 9 in ISO 10303-11:

That gives us:

entity
attr
derive
inverse
unique
where / wr
ip (<=== the addition)
function
constant
local
var
rule
procedure
subtype_constraint

Do we need these?

use from?
reference from?

TRThurman commented 3 years ago

aaah, sorry for confusion.

10.3.12 Rule label Visibility : A rule label is visible in the scope of the entity, rule or type in which it is declared. NOTE The rule label may be used by implementations or in a remark tag (see 7.1.6.3.

here is the production for WHERE clause where_clause = WHERE domain_rule ’;’ { domain_rule ’;’ } and for domain_rule 202 domain_rule = [ rule_label_id ’:’ ] expression .

so in EXPRESS ENTITY FOO; WHERE WR1: STUFF; WR2: MORE STUFF; END_ENTITY; (foo.IP1: informal proposition, ) The special case here is that the rule_label_id is specially encoded for STEP informal propositionsL

A rule_label_id string that begins with "IP" followed by a number is defined in STEPmod to be an informal proposition.

zakjan commented 3 years ago

Generally I'm following section 10.1, table 9, Scope and identifier defining items. Rule labels are identifiers, that's fine. Interface specifications (use from / reference from) are not.

Remark tags foo.WR1 and foo.IP1 are already supported, these are parsed as <id>.<child_id>.

My uncertainty is about remark tags foo.wr:WR1 and foo.ip:IP1, whether it should be parsed as <id>.<child_type>:<child_id>, interpreted as looking for items with the specified child_type only, and what are known child_type values.

Alternatively, I could ignore child_type part, and fall back to <id>.<child_id>. Duplicate identifiers shouldn't exist anyway. Is this an acceptable solution?

TRThurman commented 3 years ago

Generally I'm following section 10.1, table 9, Scope and identifier defining items. Rule labels are identifiers, that's fine. Interface specifications (use from / reference from) are not.

Remark tags foo.WR1 and foo.IP1 are already supported, these are parsed as ..

My uncertainty is about remark tags foo.wr:WR1 and foo.ip:IP1, whether it should be parsed as .:, interpreted as looking for items with the specified child_type only, and what are known child_type values.

It looks to me like it should be .. I don't see a use for the colon and RHS in the remark tag.

Alternatively, I could ignore child_type part, and fall back to .. Duplicate identifiers shouldn't exist anyway. Is this an acceptable solution?

Yes

ronaldtse commented 3 years ago

Let's just keep . then -- simplest. Then there is nothing further to do here, right @zakjan ?

zakjan commented 3 years ago

Added ignoring child_type part. <child>.<anything>:<child_id> is now parsed as <child>.<child_id>

zakjan commented 3 years ago

So that files that already use this syntax are supported by the parser

zakjan commented 3 years ago

There is still one more thing to do, add support for informal propositions as separate items.

For each remark with child_id starting with IP, move it to child.informal_propositions, and remove it from remarks, right? Where rules are allowed on entity, rule, type items, is it the same with informal propositions?

TRThurman commented 3 years ago

For each remark with child_id starting with IP, move it to `child.informal_propositions, and remove it from remarks, right? Where rules are allowed on entity, rule, type items, is it the same with informal propositions?

Yes Anywhere a domain rule is allowed an IP is allowed. But I repeat that as far as EXPRESS is concerned IPs are remarks.

zakjan commented 3 years ago

Behavior implemented:

When a matching remark tag is found, an implicit InformalProposition item is created under parent.informal_propositions. Content is available inside its remarks, because there could be multiple remarks with the same remark tag.

zakjan commented 3 years ago

The most important test confirming this: https://github.com/lutaml/expressir/blob/c1ff50200e088387ef1a2ee8dcd51f3a5e2c10e2/spec/expressir/express_exp/parse_remark_spec.rb#L59-L69

zakjan commented 3 years ago

@ronaldtse Is it good to merge?

zakjan commented 3 years ago

I assume it's fine, merging

lutaml / expressir

Support informal propositions #50