-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SPS002 - IfcFacility-part #65
SPS002 - IfcFacility-part #65
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Initial comments.
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm happy to add to the csv. Is there a better source for that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
Added something along those lines as a test here: #67 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.
|
…ability from earlier steps)
No description provided.