SPS002 - IfcFacility-part

[JTurbakiewicz]

No description provided.

[pjanck]

Initial comments.

[Ghesselink]

Looks good so far, not sure whether to look really in-depth since it is a draft PR (still WIP?).

I took the freedom to change the folder to 'sps002' and the filename for the fail file, since this caused the tests to fail. Now all the marks are green again and the autistic part of my brain can relax.

[pjanck]

I think that this csv is incomplete. For example, I believe that IfcFacilityPart can be decomposed in IfcFacilityPart as well. Where does this csv originate from?

[JTurbakiewicz]

It comes from: https://ifc43-docs.standards.buildingsmart.org/IFC/RELEASE/IFC4x3/HTML/concepts/Object_Composition/Aggregation/Spatial_Decomposition/content.html#General-Usage

I'm happy to add to the csv. Is there a better source for that?

[Ghesselink]

I feel we need a re-organization regarding relationships. This PR, ALB004 and some other PRs are very similar in functionality which make it quite confusing. Right now we have :

• nesting, aggegrating, containing, assigning relationships
• An option to specify a relationship with a custom csv file
• A couple of nuances (e.g., directly/indirectly, constraint on number of relating elements)
• Slightly unstructured error classes

Maybe we could make a start with all punt the third point (the nuances) and place them into a single @then statement. Something like :

@then('Each {entity} must be {relationship} to {other_entity}
@then('Each {entity} must be {relationship}{if_asper} {condition}

The structure is then always:
Entity -> Relationship -> entity -> optional condition
And the more nuanced, 'advanced', statements are then :
Entity -> Relationship -> advanced requirement -> Entity
Some examples of optional condition :

• 'As per {table}'
• 'If {another_entity} is present'

And advanced requirements :
'at most 3 instance(s) of'
'only by the following entities:'
This condition we could parse as in #48

I feel this would result in clearer implementation and ease writing future rules and it's better to start with the cases that are the most similar (without the advanced statements). On the other hand, it will perhaps add more complication on github, as there are now many open PR and not a clear overview.
What do you think? @JTurbakiewicz

[JTurbakiewicz]

Added something along those lines as a test here: #67
What do you think? @Ghesselink

I'll be adding some more test cases there, so I'll most likely change some stuff still, but it's perhaps a reasonable start.

I feel we need a re-organization regarding relationships. This PR, ALB004 and some other PRs are very similar in functionality which make it quite confusing. Right now we have :

• nesting, aggegrating, containing, assigning relationships
• An option to specify a relationship with a custom csv file
• A couple of nuances (e.g., directly/indirectly, constraint on number of relating elements)
• Slightly unstructured error classes

Maybe we could make a start with all punt the third point (the nuances) and place them into a single @then statement. Something like :

@then('Each {entity} must be {relationship} to {other_entity}
@then('Each {entity} must be {relationship}{if_asper} {condition}

The structure is then always: Entity -> Relationship -> entity -> optional condition And the more nuanced, 'advanced', statements are then : Entity -> Relationship -> advanced requirement -> Entity Some examples of optional condition :

• 'As per {table}'
• 'If {another_entity} is present'

And advanced requirements : 'at most 3 instance(s) of' 'only by the following entities:' This condition we could parse as in #48

I feel this would result in clearer implementation and ease writing future rules and it's better to start with the cases that are the most similar (without the advanced statements). On the other hand, it will perhaps add more complication on github, as there are now many open PR and not a clear overview. What do you think? @JTurbakiewicz