Code structure and parsing of 'entity to value' and 'entity -> relationship -> entity'

[Ghesselink]

Shifting all discussions related to this topic here, as it spans across multiple pull requests.

Earlier discussion with Jakub #62

In response to Stefan's comment #80 (comment), it might be beneficial to consider reorganizing the structure. Broadly speaking, when parsing Gherkin statements related to values and attributes, it seems we encounter two distinct scenarios:

Direct value-to-attribute linkage, as observed here, such as "The type of the attribute 'Items' must be IfcCurveSegment."
Through relationships: mapping from one entity to another, like "An IfcAlignmentSegment nests an IfcAlignmentHorizontalSegment". This can further have a conditional statement: "value -> relationship -> entity -> condition".

Intuitively, I think this approach would simplify the process by parsing the information into more manageable chunks, leading to more consistent and replicable code. This would consolidate relationship terms (like nesting, containing, associating) into one location alongside the entities (e.g., IfcRelAssigns, IfcRelAssociates, etc.). The conditions can be categorized separately, encompassing clauses like "if X is present", "a list of only", or "num instances of".

Regarding the condition to a 'given' statement. Currently it's kind of mixed, perhaps adding to the horror and inconsistency. For instance

  Given A file with Model View Definition "CoordinationView"
    And A file with Schema Identifier "IFC2X3"

   Then There must be at least 1 instance(s) of IfcBuilding
    And The IfcBuilding must be assigned to the IfcSite if IfcSite is present
    And The IfcBuilding must be assigned to the IfcProject if IfcSite is not present

Change to

 Background: 
  Given A file with Model View Definition "CoordinationView"
    And A file with Schema Identifier "IFC2X3"

  Scenario 1 : The IfcBuilding must be assigned to the IfcSite if IfcSite is present
   Given IfcSite is present # condition 
   Then A relationship from IfcBuilding to IfcSite  # entity -> rel -> entity
   And The relationship is must be 'assigned'

   Scenario 2: # The IfcBuilding must be assigned to the IfcProject if IfcSite is not present
  Given IfcSite is not present
  Then  A relationship from IfcBuilding to IfcSite # or to/from, as @aothms implemented before
   And The relationship is must be 'assigned' # entity -> rel -> entity

  Scenario 3: 
   Then There must be a least 1 instance(s) of IfcBuilding

Or

  And An IfcAlignment
  Then Each IfcAlignment must be directly contained in IfcSite

To

Given An IfcAlignment
And A relationship from IfcAlignment to IfcSite
Then The relationship is 'directly contained'

A potential addition could involve adding an extra table to the database that stores previously identified relationships between two entities. This could optimize the search process; if we already know that the relationship between IfcEntity1 and IfcEntity2 is defined as ["X"], the system can begin its search based on this established connection.

[evandroAlfieri]

@aothms @Ghesselink is this still valid or obsolete?