pass-predefined_properties_are_supported_but_discouraged_1_2

[rubendel]

Personally I don't think this complies with "simple" anymore, as it was set out in project goals. Also it is ambiguous, the exact same IDS spec would also match a regular property Foo_Bar.PanelOperation = "SWINGING". Granted, the spec is already ambiguous because properties/quantities are both implemented as properties, but this is another step I would say.

There is no good way of implementing this generically, which means that each implementation will have to implement IfcDoorLiningProperties, IfcDoorPanelProperties, IfcPermeableCoveringProperties, IfcReinforcementDefinitionProperties, IfcWindowLiningProperties, IfcWindowPanelProperties. Each of these have different attributes.

If this stays in spec, I think it should be described which attributes should be supported (I am guessing the same criteria apply as for the attributes facet).

[Moult]

Yes, if supported, the same criteria as attributes would apply.

I also am not a fan of supporting these, but apparently there is a usecase for them.

[pasi-paasiala]

Remove the test case in 1.0.

[giuseppeverduciALMA]

if discouraged, it is better not to encourage their use by supporting them with IDS

[aothms]

Most of the predefined property sets are deprecated in IFC4.3. That's why usage could be considered discouraged, but in IFC4 there is no standardized agreement on exchanging this content in regular property sets, so I don't think we have the mandate in the IDS group to actively discourage them in IFC4.

[NickNisbet]

But there are replacement property sets:

• Pset_DoorLiningProperties
• Pset_DoorPanelProperties

Regards,

Nick.

[aothms]

Yes, but only in 4.3

HISTORY New property set in IFC4.3.2.0 to replace the entity IfcDoorLiningProperties

https://ifc43-docs.standards.buildingsmart.org/IFC/RELEASE/IFC4x3/HTML/lexical/Pset_DoorLiningProperties.htm

[CBenghi]

@aothms, We have a question about any priority of this type of property over an identically named property in a standard property-set. Which one should prevail?

The call has agreed to implement all types, listed in the OP issue, which will have to be documented.

Implementation notes:

• Because the property set name in many IFC examples we have seen is left empty by the exporting applications, a good solution would be to match them by property name alone (regex for the pset name).
• A possible solution for multiple conflicting property values is to treat them as an enumeration. Possibly to be documented.

[aothms]

Sorry. Not sure whether I fully understand. According to the spec we can have the following instantiations:

IfcDoor <- IfcRelDefinesByProperties -> IfcDoorPanelProperties[PanelOperation=SWINGING]

IfcDoor <- IfcRelDefinesByProperties -> IfcPropertySet[Name=Pset_DoorPanelProperties] -> IfcPropertyEnumeratedValue[Name=PanelOperation, EnumerationValues=[SWINGING]]"

So conflicts can only arrise when:

• People name an IfcPropertySet with Name=IfcDoorPanelProperties, which I think is a bit pathological
• IDS does not define the propertySet, but only the property. But in that case conflicts can happen anyway regardless of being predefined or vannilla psets, so the behaviour there needs to be consistent.

[giuseppeverduciALMA]

@aothms if you take a look at the test case

fail-predefined_properties_are_supported_but_discouraged_2_2:

<property datatype="IfcDoorPanelOperationEnum" minOccurs="1" maxOccurs="1">
  <propertySet>
      <simpleValue>Foo_Bar</simpleValue>
  </propertySet>
  <name>
      <simpleValue>PanelOperation</simpleValue>
  </name>
  <value>
      <simpleValue>SWONGING</simpleValue>
  </value>
</property>

#8=IFCDOORPANELPROPERTIES('16MocU_IDOF8_x3Iqllz0d',$,'Foo_Bar',$,$,.SWINGING.,$,.LEFT.,$);

the propertySet is the name of the IfcDoorPanelProperties entity, not IfcDoorPanelProperties.

Is the test case wrong?

[CBenghi]

I think in the call we were thinking of an IFC file that might look like this:

#7=IFCDOOR('2nJrDaLQfJ1QPhdJR0o97J',$,$,$,$,$,$,$,$,$,$,$,$);

#8=IFCDOORPANELPROPERTIES('16MocU_IDOF8_x3Iqllz0d',$,'Foo_Bar',$,$,.SWINGING.,$,.LEFT.,$);
#9=IFCRELDEFINESBYPROPERTIES('1xdwj8qGXK4hzoNbvMdXJW',$,$,$,(#7),#8);

#10=IFCPROPERTYSET('16MocU_IDOF8_x3Iqllz0d',$,'Foo_Bar',$,(#11));
#11=IFCPROPERTYSINGLEVALUE('PanelOperation',$,IFCDOORPANELOPERATIONENUM(.ROLLINGUP.),$);
#12=IFCRELDEFINESBYPROPERTIES('1xdwj8qGXK4hzoNbvMdXJW',$,$,$,(#7),#10);

The two values would share the same pset name and property name.

Would this be illegal IFC?

[aothms]

Ok, turns out I'm wrong on many fronts as always. IFC never ceases to surprise you.

Would this be illegal IFC?

I thought so, because of [0], but turns out not to be because of [1] where at line 11 specifically only the names of vanilla psets are considered and not those of predefined psets. I don't know if this is intentional or an oversight.

[0] https://ifc43-docs.standards.buildingsmart.org/IFC/RELEASE/IFC4x3/HTML/lexical/IfcUniqueDefinitionNames.htm [1] https://ifc43-docs.standards.buildingsmart.org/IFC/RELEASE/IFC4x3/HTML/lexical/IfcUniquePropertySetNames.htm

the propertySet is the name of the IfcDoorPanelProperties entity, not IfcDoorPanelProperties.

Many thanks @giuseppeverduciALMA that is indeed where I was confused. I somehow thought that for predefined psets we would assign the entity name as the propertySet and not the value of IfcPredefinedPropertySet.Name. I don't know if that would be better, there would still be the possibility of having multiple IfcDoorPanelProperties with or without different names altogether.

Then I don't think there is a lot we can do at this point. Maybe we should have had an entity field in the property facet where you could express an optional requirement of IfcDoorPanelProperties|IfcPropertySet|...

But a requirement facet being evaluated on multiple elements within the same applicability is not new:

• Multiple materials in a material layerset
• IfcPropertyListValue
• No property set, only property (or is that no longer allowed).

I think we picked all (and not any) as the aggregate function to use in these cases (but could have changed since my involvement, don't know). So also in this case we just need to handle that in the same fashion. If you have both a predefined propertyset and a vanilla propertyset defining the same name and property definition, then both need to be evaluated and consistent for the predicate to pass (?).