Contradictory rules for Pset prefix usage

Developers Validation Service
1

According to the buildingSMART documentation on IfcPropertySet for IFC 2x3

In addition any user defined property set can be captured, those property sets shall have a Name value not including the “Pset_” prefix.

The validator rule PSE001_Standard-properties-and-property-sets-validation.feature on the other side states

The rule verifies that each IfcPropertySet starting with Pset is defined correctly.

Which is it? Are custom Pset names allowed that start with “Pset-”?
If yes, then the validator rule has to be corrected.
If no, then the IFC 2x3 documentation has to be corrected.

2

Th Pset_ prefix is reserved for standard property sets. What the IFC Validation Service does is checking that when a property set starts with Pset_ it is indeed one of the standard ones.

That rule does more than that, e.g., checking that properties inside a standard property set are the correct one, checking the data type, checking correct assignment to object, etc.

If you check the scenarios that compose the rule, you’ll have a complete view.

For this, the description of the rule has been generalised by saying “defined correctly”. However, if you want to suggest a richer, more comprehensive description of the rule feel free to make a suggestion in GitHub directly. Thanks for your contribution.

3

The PSE001 rule actually says Pset rather than Pset_, while the documentation specifically says Pset_.

That’s why my question mentioned a custom Pset starting with Pset-.

4

Ok, I see now. We already got a similar feedback.

PSE001 strictly checks what the documentation currently says, hence Pset_.

The team is already working on making it explicit in the PSE001 scenario (currently saying just Pset). The team is also working on an additional Industry Best Practice rule that checks for the generic case. As in, [pP][sS][eE][tT] with any separator (_, -, ., blank space, etc.)

1 Like