Open berlotti opened 4 years ago
WHERE Rules are actually documentation about restrictions. They are not parsed / evaluated at run-time because that is too late. The WHERE rules semantics should be in documentation in a different way.
There is a desire to have machine readable restrictions to facilitate automatic checkers (additional to documentation). mvdXML is not capable of doing this.
WHERE rules are used for file validation, e.g. during the certification process. Therefore they do have a purpose. Also being able to declare restrictions in a computer-interpretable way (rather then my pure text documentation) is a benefit for the consistency check of IFC exchanges.
Hence I see it as premature to generally remove WHERE rules (while I agree that several could be removed).
I like WHERE rules. They are implemented in XBim very well and that teached me a lot about the rules in valid IFC files. The fact, that implementers to not respect the standard, is for me not a reason to leave them out (and I am myself an implementer 😀 ).
For me it would be ok, when I would know, that I have a file that does not respect the where rules.
Quality level 1: file that does not check WHERE rules on import or export Quality level 2: file that checks WHERE rules on import or export
Since nobody else is putting this on github, here we go....
Description of the proposal: The ISG questionaire last year clarified that vendors are not parsing WHERE rules. It also clarified that WHERE rules are almost never needed in practical use cases (with a few exceptions). Since the WHERE rules are not being used anyway, and are typical STEP/EXPRESS heritage, I suggest to remove them from the schema. Specific cases that need additional restrictions will be looked at case-by-case.
Describe how it contributes to the objectives set in https://github.com/buildingSMART/NextGen-IFC/wiki/Towards-a-technology-independent-IFC: Makes it STEP/EXPRESS independent.
What do we win: Interoperability
What do we loose: According to the ISG Questionnaire nothing in practice.
Schema impact: Simpler
Instance model impact: none
Backwards compatible: no in theory, yes in practice because it is not used
Automatic migration possible: yes, because files don't use it