Open pasi-paasiala opened 4 years ago
For geolocation in IFC2X3, the unofficial standard of EPset_
was created to represent an endorsed by buildingSMART but "not yet in the spec" pset.
If Pset_
and Qto_
is removed, then EPset_
can also be removed.
agree, but I would refer to issue #28.
If we have a clearly defined publication and referencing of those properties and quantities that are part of the international IFC specification, ISO 16739, then we don't need such prefixes anymore. Then any system can look-up the official publication to identify, whether it is an international property sets by definition, or not.
A PSet (again a set, not a list) is a fixed list of properties, for exactly one purpose. As we all know, the world is full of PSets, but more in the meaning of data templates:
Important will be the usage of agreed property definitions, but the data templates will be more dynamic. IFC itself has a good mechanism and semantics with the IfcSimplePropertySetTemplate
and IfcComplexPropertySetTemplate
. Why do we not use that, instead of PSet and QSets?
Consensus: change namespace. For example: bSI.wallCommon
Description of the proposal:
Having "Pset" and "Qset" as prefix for "official" property sets is quite funny. Could the prefix be something else, like IFC, or nothing. Why do we need them?
What do we win:
More meaningful property set names
What do we loose ?
Schema impact: None
Instance model impact: Small
Backwards compatible: None
Automatic migration possible: ?
Additional implications:
- Note that not all points need to be satisfied! Backwards compatibility and file size are not concerns.