The old XIDS implementation of SchemaInfo.GetAttributeClass() will only return the relevant IFC classes where the class derived from IfcRoot. In the latest implementation in this Audit tool it returns all classes including non-rooted types.
So getting classes which have an attribute 'Description' now includes classes such as IFCCLASSIFICATION, IFCORGANIZATION etc. which are not rooted, rather than just IFCOBJECT and IFCTYPEOBJECT
Is that by design? Appreciate it may be technically correct, but it also opens up a few complexities for IDS validator implementors (particularly early bound IFC implementors) - especially where there may be multi-part applicability facets. e.g.
_Applies to all elements with Attribute Name of 'Description' and a Property Set 'ePsetFoo.Bar'
... we'd made an assumption that an Attribute Facet "Selector" would return IfcObjectDefintions/Roots, but it seems actually there may no useful common ancestor, meaning we'd need to type check at a finer level before applying the Pset predicate. Not a big major deal but wanted to check the expected behaviour before doing the work.
PS. I've seem some IDS examples where the presence of an Attribute name is used as a means of selecting a hierarchy of IFC classes -essentially making up for the fact that IDS lacks subType support on Entity Types (e.g. using presence of attributes such as GlobalId and Tag to select all IfcRoots, or IfcElements). Feels a bit of a hack, but I guess this may also raise similar issues if implementors have a different interpretation of what Attributes belong to.
In summary:
is the change to GetAttributeClass() expected?
Should there be any audit rules on what can be done using this kind of attribute as selector approach?
The old XIDS implementation of
SchemaInfo.GetAttributeClass()will only return the relevant IFC classes where the class derived from IfcRoot. In the latest implementation in this Audit tool it returns all classes including non-rooted types.So getting classes which have an attribute 'Description' now includes classes such as IFCCLASSIFICATION, IFCORGANIZATION etc. which are not rooted, rather than just IFCOBJECT and IFCTYPEOBJECT
Is that by design? Appreciate it may be technically correct, but it also opens up a few complexities for IDS validator implementors (particularly early bound IFC implementors) - especially where there may be multi-part applicability facets. e.g.
_Applies to all elements with Attribute Name of 'Description' and a Property Set 'ePsetFoo.Bar'
... we'd made an assumption that an Attribute Facet "Selector" would return IfcObjectDefintions/Roots, but it seems actually there may no useful common ancestor, meaning we'd need to type check at a finer level before applying the Pset predicate. Not a big major deal but wanted to check the expected behaviour before doing the work.
PS. I've seem some IDS examples where the presence of an Attribute name is used as a means of selecting a hierarchy of IFC classes -essentially making up for the fact that IDS lacks subType support on Entity Types (e.g. using presence of attributes such as GlobalId and Tag to select all IfcRoots, or IfcElements). Feels a bit of a hack, but I guess this may also raise similar issues if implementors have a different interpretation of what Attributes belong to.
In summary:
GetAttributeClass()expected?