How to ask for occurrences of IfcAirTerminal(Type) in case of IFC2x3?

[MatthiasWeise]

From IFC2x3 specification: “The occurrences of the IfcAirTerminalType are represented by instances of IfcFlowTerminal or its subtypes.”

Current IDS entity facet does not allow to restrict IfcTypeObject, which would be needed in case of above example for IFC2x3.
Or is there another way to handle this case?

Proposed extension (adding optional typeObject restriction to entity facet) is also relevant for #88.

[aothms]

At some point it was discussed to make, what is currently, partOf more general, so that you'd be able to say something like:

applicability
  entity
    IfcFlowTerminal
  relates
    relationship: IfcRelDefinesByType
    entity: IfcAirTerminalType

or

applicability
  entity
    IfcFlowTerminal
  relates
    attribute: IsDefinedBy
    entity: IfcAirTerminalType

The concern was the introduced complexity for authoring and checking in non-ifc environments, etc.

Therefore this is indeed currently a limitation. typeObject on entity sounds reasonable, but indeed is a bit messy on non-object entities.

One other alternative is that we allow IfcAirTerminal even in IFC2X3 IDS'es and write a rule that this expands to IfcFlowTerminal+IfcAirTerminalType. We encode this in a table as part of the spec. Which is also nasty, but would make the IDS compatible with IFC4 and doesn't require a schema change.

[MatthiasWeise]

Using IfcAirTerminal is most likely the most convenient solution for IDS users (IFC schema version independent). However, I do not like agreements captured in additional tables.

Using the PartOf facet might work as well, although "PartOf" suggests a different semantic meaning. Technicaly, this comes close to the typeObject setting in the entity facet.

Another potential type of confusion is the predefinedType setting: in above example it need to be checked on IfcAirTerminalType (maybe not that critical, but worth to point out).

[dro007]

This is a critical issue. IFC2x3 needs to be supported in IDS v1.0

[Moult]

This is a fundamental problem in IFC, not in IDS, I believe. IFC2X3 did not have the EXPRESS rules that restricted the class-pairs to be used for types and occurrences. I'm not sure it's up to IDS to make up for this shortcoming.

[MatthiasWeise]

We cannot change IFC2x3 and somehow have to deal with this issue. Not sure what will be the best solution or maybe a proper workaround. The alternative proposed by @aothms might be such workaround without touching the schema. Just have to be agreed and documented.

(One other alternative is that we allow IfcAirTerminal even in IFC2X3 IDS'es and write a rule that this expands to IfcFlowTerminal+IfcAirTerminalType.)

[TLiebich]

as an additional thought - about 95% of all IFC file running around in the moment in industry are IFC2x3 files (whether we like it or not), so without a solutiion here and now for IDS 1.0 it will be rather useless for checking MEP models in the moment.

[CBenghi]

We cannot change IFC2x3 and somehow have to deal with this issue. Not sure what will be the best solution or maybe a proper workaround. The alternative proposed by @aothms might be such workaround without touching the schema. Just have to be agreed and documented.

(One other alternative is that we allow IfcAirTerminal even in IFC2X3 IDS'es and write a rule that this expands to IfcFlowTerminal+IfcAirTerminalType.)

I truly dislike this idea.

When we started to develop IDS we tried to define information requirements remaining relatively IFC agnostic, but we have recently moved in closer alignment to the schema.
Injecting mapping behaviours to make an IDS work for multiple schemas seems like something that will complicate implementation a lot.

The way I see it, we are doing all this to make it simple to write code elsewhere in the supply chain to go and get the information in a robust way; if we inject custom behaviours by type this will impact the entire industry when they go and search for this information in models, as they will have to replicate our maps.

I think this is would not be beneficial to the industry.

[MatthiasWeise]

I guess there are two sides of the coin here, make it easy for (1) users = IFC agnostic or (2) software implementation = closer to the IFC schema. I was orginally thinking about a new attribute typeObject (more towards 2).
@CBenghi What are you proposing?

[berlotti]

There seem to be two sides of the coin, but I see a different coin.
1- create a standard that is symmetric, predictable and therefore easy to implement
2- create a thing that hangs together from exceptions just to support some kind of use-case
I opt for option 1. That choice has consequences. We need to accept the consequences.

We had a seperation between Typeobjects and instances (and where to put property sets) in a previous version of IDS (version 0.5 had it for example). That has been removed by group consensus to keep IDS predictable. I remember there were too many unclarities and questions about how the overruling of IFC would work when defining these things in IDS.
The reasoning back then was to use the rules of IFC when it comes to typing.

For the example of IfcAirTerminalType and IfcFlowTerminal it would mean that requiring one would mean the requirement is according to the IFC schema.
Good documentation and some examples of this would be needed indeed.

[aothms]

The coin I see here is:

• Implicit solution (supplementary lookup table that nobody likes)
• Explicit solution (new attribute solely for a very specific case, also not desirable).

I say for devs it's roughly the same, just a bit more work. We'll have comprehensive test cases in both options, so I don't see a big disadvantage or advantage in both solution directions. It's more a conceptual question for me.

But great work on noticing this issue @MatthiasWeise

It's annoying that ifc2x3 has these exceptions and I don't think there is a particular clean solution possible in IDS. But for me, the implicit solution at least keeps the IDS schema itself a bit cleaner. Knowing that 2x3 is a 15 year old version, when 2x3 is finally obsolete, we can remove the lookup table from the documentation, but the attribute cannot be removed in a backwards compatible fashion.

[Moult]

If anybody is after a computer map of 2X3 elements to types I produced this after coming across the same problem in IFC2X3: https://github.com/IfcOpenShell/IfcOpenShell/blob/v0.7.0/src/ifcopenshell-python/ifcopenshell/util/entity_to_type_map_2x3.json

[aothms]

@Moult

This is a fundamental problem in IFC, not in IDS, I believe. IFC2X3 did not have the EXPRESS rules that restricted the class-pairs to be used for types and occurrences. I'm not sure it's up to IDS to make up for this shortcoming.

I think the issue is a different one. It's not about enforcing relationship between Object and TypeObject, but rather the ability to select an IfcAirTerminal Object which only exists as a IfcFlowTerminal - IfcAirTerminalType pair in 2x3.

[Moult]

Oh right I see, that's a bit of a weird requirement then. What's the original requirement in plain English?

[MatthiasWeise]

I really wonder about this discussion, in particular about this statement:

It's annoying that ifc2x3 has these exceptions and I don't think there is a particular clean solution possible in IDS. But for me, the implicit solution at least keeps the IDS schema itself a bit cleaner. Knowing that 2x3 is a 15 year old version, when 2x3 is finally obsolete, we can remove the lookup table from the documentation, but the attribute cannot be removed in a backwards compatible fashion.

I wonder, because you (Léon, Thomas, ..) are proposing exactly this for IFC5 as an improvement!
Citation from your publication (if I remember well it was ECPPM): "Future of the Industry Foundation Classes: towards IFC 5"

We propose to make the element type mandatory, such that the specialization of IfcElement is no longer necessary. A door will become an IfcElement of an IfcDoorType. As a result, more than hundred entities can be removed from the schema.

[aothms]

If it's done consistently it's not an exception anymore.

I think there's two things here for IFC5 we need to remember. Exceptions are painful. That's what we're seeing in this thread. But also, laborious modelling efforts (the complete replication of occurrence and type trees) will make people desperate enough to come up with exceptions (we had a similar discussion in 4.3 with the selects of predefined types, which in the end was rewritten to the more laborious explicit entity types equivalent buildingSMART/IFC4.3.x-development#90).

We'll have to see how well this IFC5 paper ages, but combined with the latebinding (built element type as string) and pset'ification (favouring psets over direct built element attributes) already happening since IFC4, I don't think this is particular statement is very contentious.

Let's go back on topic.

[MatthiasWeise]

I don't see a big difference between the IFC5 proposal and IFC2x3. It is maybe more consistent, but actually leading to the same technical problem:

How to specify a check for occurrences of IfcAirTerminalType?

• Can we use IfcAirTerminal even if such entity does not exist in the schema (look-up table solution)?

• Or shall we use IfcAirTerminalType limiting the scope of IDS to check of occurrences (or how to differentate from checking the type object instead of occurrence if type object checks should be in scope of IDS)?

Possible solutions are more less on the table, we just have to make a decision!

1. Lookup table being maybe more easy for IDS creators (and to some extend allows to be IFC agnostic as supported by IDS). Disadvantabe is to split IDS specification into several documents (although having it already with our unit/measurement table).

2. Make suggested changes to the IDS schema and be more close to the IFC schema (release). I guess this is the preferred solution for model checking implementations.

[TLiebich]

good summary by @aothms and @MatthiasWeise

please decide whether solution 1 or 2 should be chosen, personally I would opt for solution 2 - add "typedBy" which gets $entityName . "Type" as default value but can be overriden by the explicit type as in case of IFC2x3 MEP classes. But also the lookup table seems fine for me.

Not addressing the issue, meanwhile well explained, introduces the risk, that IDS 1.0 is of far less practical value to satisfy todays ifc2x3 validation needs in construction projects.

[Moult]

I'm still struggling to see what the practical information requirement is. It sounds a bit academic so far.

[TLiebich]

here the user story:

The user would like to validate the required properties associated to an air terminal and a socket. Both requirements are different (different required properties exists for air terminal and an outlet). Therefore in IDS the applicable IFC class needs to be addressed.

In IFC4 there is a (mainly) 1 to 1 synchronization of IFC occurrence and IFC type classes - here IfcAirTerminal > IfcAirTerminalType, IfcOutlet > IfcOutletType - plus the WHERE rules to ensure a consistent instantiation. Selecting IfcAirTerminal or IfcOutlet supports the validation of different required properties.

In IFC2x3 within the sub tree of IfcDistrubutionElement this synchronization does not exists. here IfcFlowTerminal > IfcAirTerminalType, IfcFlowTerminal > IfcOutletType. If IDS only allows to select the IFC occurrence class - here IfcFlowTerminal, how to validate that the air terminal requires other properties as the outlet?

does this makes the issue clear?

[Moult]

Yes that makes sense. To a small degree specifying the predefined type (which is inherited) may help. Thanks for clarifying :)

[TLiebich]

unfortunately not - in IFC2x3 MEP elements, the predefinedType was only defined for the types, the occurrence class IfcFlowElement has no way to express the predefined type.

[Moult]

@TLiebich yes but in IFC the rule is that the predefined type is "inherited" from the type.

[TLiebich]

@Moult - correct (I might have written this rule in the past ;-))

my point was, that if in IDS 1.0 we cannot address the type, if it is different to $entityName . "Type", then we can also not use the predefined type inherited from the type object.

[MatthiasWeise]

@Moult Relying on PredefinedType could indeed help to some degree, but not in all cases and most likely less efficient.

Possible scenario from my point of view:

• use entity name of the occurrence or may even leave it empty (entity facet seems to be optional in IDS for applicability, right?)
• define PredefineType, which seems to be mandatory in IFC for all instantiable IfcTypeObjects:
  -> This enables to find the proper IfcTypeObject unless it is USERDEFINED or NOTDEFINED (also assuming that enumeration values are unique across different enums).
• in case of USERDEFINED:
  -> use attribute facet for checking ObjectType attribute
• in case of NOTDEFINED:
  -> edge case without solution

There is another important "edge case" without solution:
If users do not care about PredefinedType and thus leave it empty on purpose (i.e. define requirements for all options).

[aothms]

Let's try and wrap this up.

With IDS we chose on purpose some level of abstraction over IFC classes directly. We have material targetting all subtypes of material definition. We have property targeting a variety properties and quantities. The abstraction over direct usage of IFC classes causes a need for increased clarity in docs and test cases, resulting in ease of use for end-users and improved compatibility between IFC releases.

If we take that as a starting point, to me, solving this issue in documentation (extra lookup table, to convert IfcAirTerminal to IfcFlowTerminal+IfcAirTerminalType) is most in line with these guiding principles. Adding an attribute for something that is in day to day usage already constrained in the schema is a recipe for error and confusion.

If we decide against supplementary table, I prefer to leave this as a limitation of IDS+IFC2X3. I.e that end-users will either have to specify constraints on the more general IfcFlowTerminal or require them on the IfcAirTerminalType or upgrade to IFC4.

[Moult]

I'm fine with either solution. I have a small personal bias to encourage people to upgrade to IFC4. IFC2X3 is ancient. Get a move on, or this will hurt IFC in the long term as it will get a reputation for being decades out of date.

[TLiebich]

I opt for an extra lookup table and the ability to create an IDS file for IFC2x3 with IfcAirTerminal.

PS: while I would be more then happy when the industry moves faster to IFC4, I think it is the wrong approach to push it via an in scope of IFC2x3 incomplete IDS specification in scope of IFC2x3.

[MatthiasWeise]

@CBenghi If we agree on a lookup table (i.e. enable to use IFCAIRTERMINAL in IFC2x3), the checking tool must be extended to include those IfcXxx[Type] entities as well.

[andyward]

Agreed, feels like the audit tool should warn when using an entity type this is 'inferable' this way. At the moment this IDS will throw an error in the Audit tool, but meets the proposal to handle via a mapping table

<ids xmlns="http://standards.buildingsmart.org/IDS" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://standards.buildingsmart.org/IDS/ids_05.xsd">
    <info>
        <title>Pass-IFC2x3 doesn't have AirTerminal instance, but does have AirTerminalType which can be used to infer instance</title>
    </info>
    <specifications>
        <specification name="IFC2x3 doesn't have AirTerminal instance, but does have AirTerminalType which can be used to infer instance" ifcVersion="IFC2X3" minOccurs="1" maxOccurs="unbounded">
            <applicability>
                <entity>
                    <name>
                        <simpleValue>IFCAIRTERMINAL</simpleValue>
                    </name>
                </entity>
            </applicability>
            <requirements>
                <entity>
                    <name>
                        <simpleValue>IFCFLOWTERMINAL</simpleValue>
                    </name>
                    <predefinedType>
                        <simpleValue>GRILLE</simpleValue>
                    </predefinedType>
                </entity>
            </requirements>
        </specification>
    </specifications>
</ids>

Test IFC for reference

ISO-10303-21;
HEADER;
FILE_DESCRIPTION (('ViewDefinition [CoordinationView]'), '2;1');
FILE_NAME ('pass-ifc2x3-air_terminal_edge_case.ifc', '2023-05-03T18:17:26', ('AW'), ('xbim Ltd'), 'xbim Toolkit', 'xbim IDS Unit tests', 'n/a');
FILE_SCHEMA (('IFC2X3'));
ENDSEC;
DATA;
#1=IFCAIRTERMINALTYPE($,$,'AirTerminalType',$,$,$,$,$,$,.GRILLE.);
#2=IFCFLOWTERMINAL($,$,'AirTerminal',$,$,$,$,$);
#3=IFCRELDEFINESBYTYPE($,$,$,$,(#2),#1);
ENDSEC;
END-ISO-10303-21;

This does raise a question about "forward mapping" of types from newer schemas to older ones where the type did not exist - and how the audit tools should treat these. I see a few categories of this:

1. New entities that may be inferable in old schemas via a Type relationship. i.e. the topic being discussed
   IFCAIRTERMINAL, IFCELECTRICAPPLIANCE, IFCBOILER etc

2. New entities which replaced an obsolete item in an older schema
   IFCDOORSTYLE => IFCDOORTYPE, IFCBUILDINGELEMENT=>IFCBUILTELEMENT

Should a user be able to use the newer DoorType in IFC2x3, or a DoorStyle in IFC4.3? Obviously they could split the specifications by IfcVersion as a work around?

3. New entities with no obvious map in a older schema (except for an super type)
   IFCROAD, IFCKERB, IFCTRACKELEMENT etc

I don't see a way for these to be handled. They are exclusive to the newer schema.

When thinking about the auding, I'd propose 1) is a warning and 2) & 3) probably errors unless we have some implementors agreements?

[MatthiasWeise]

@andyward I am not sure if I understand the "forward mapping" proposal: in each specification we have the ifcVersion attribute allowing to specify the IFC version(s) to which the requirement rules apply. So, I am not sure if we need an agreement for mapping between IFC versions.

For the lookup table for IFC2x3: For missing occurrence entities I was actually thinking about a simple rule: check if either the given entity name or entity name + TYPE exists in the specified schema (IFCAIRTERMINAL or IFCAIRTERMINALTYPE).
If yes, the IDS file is valid. Then we do not need a fixed lookup table.
If I am not wrong we do not need to take care about STYLE, because occurrence entities for IfcWindow(Style) and IfcDoor(Style) exists in IFC2x3 (the issue is only with HVAC entities).

[andyward]

@MatthiasWeise I guess I was just seeing the concessus on this issue that (due to the design decisions on Entity facets) we proposed a special-case treatment for certain entities where we'd implicitly remap some IFC4 entity types to the best IFC2x3 equivalent using a Type as the discriminator.

i.e. we've been discussing a table of exceptions that map IFCAIRTERMINAL in IFC4+ to IFCFLOWTERMINAL defined by an IFCAIRTERMINALTYPE in IFC2x3. I'm interpreting that as a form of mapping between ifc schemas.

Your approach of just locating a Type conventionally is probably just as valid. Either way the audit tool should treat these exceptions slightly differently to an invalid entity type - and your approach could be easier and to implement.

In implementing a mapping approach for these 25+ special cases we realised the same map could be used to re-write other edge cases. But rather than hijack this issue I'd suggest we pick up separately as if anything it's a nice to have for a future release.

[andyward]

For anyone else implementing, these were the exceptions we identified that needed mapping:

i.e. these are new objects in Ifc4 that had a TypeObject in Ifc2x3, nested under their best available Ifc2x3 ObjectType

IFCFLOWTERMINAL
  IFCAIRTERMINAL
  IFCELECTRICAPPLIANCE
  IFCFIRESUPPRESSIONTERMINAL
  IFCLAMP
  IFCLIGHTFIXTURE
  IFCOUTLET
  IFCSANITARYTERMINAL
  IFCWASTETERMINAL

IFCFLOWSEGMENT
  IFCPIPESEGMENT
  IFCDUCTSEGMENT
  IFCCABLECARRIERSEGMENT
  IFCCABLESEGMENT

IFCENERGYCONVERSIONDEVICE
  IFCBOILER
  IFCCHILLER
  IFCCOOLEDBEAM
  IFCTRANSFORMER
  IFCUNITARYEQUIPMENT

IFCFLOWSTORAGEDEVICE
  IFCTANK

IFCFLOWCONTROLLER
  IFCAIRTERMINALBOX
  IFCDAMPER
  IFCELECTRICTIMECONTROL
  IFCFLOWMETER
  IFCPROTECTIVEDEVICE
  IFCSWITCH

There are some new types such as IFCCOMMUNICATIONSAPPLIANCE that can't use the same approach becasuse their TypeObject was new in Ifc4

[MatthiasWeise]

Having a fixed mapping table might be even better as I am not sure if there are exceptions to my rule.
However, is this list really complete? I am missing for instance IfcActuator, and maybe more.

I am also wondering if IFCFLOWTERMINAL + IFCAIRTERMINALTYPE is still valid IFC4?
It seems it is, because IFCFLOWTERMINAL is not ABSTRACT and I have not found a WR restricting this combination. I guess it is still allowed to keep compatibility between IFC2x3 and IFC4.
This would mean that for IFC4 model checking we cannot rely on occurrence entity only, but have to check the type entity as well, similar to IFC2x3 model checking with agreed mapping table.

[andyward]

Will have to review - it's almost certainly not complete as it was a manual review... Thought I'd share as it's not just an issue for one or 2 element types, or a single domain. We have some analysis somewhere on the added/removed entities at each schema (a bit easier to query than the changelogs)

Regarding the 2nd part - whether we need this mapping 'shim' on schemas newer than Ifc2x3, this feels like it opens a whole new set of issues, and is probably best left for future? Surely there will be other scenarios where a more specific IFC type could have been used and where there may not be a WR restricting usage? Not just these examples, but others where an equivalent type exists in 2x3. Inheritance support might help pick these up but that's another issue: #146

Going back to the original issue here, in Ifc2x3 it's seemingly impossible in IDS1.0 to define a applicability or requirements for an AirTerminal, or any of the 25+ new schema types in IFC4. We need to be able to define valid IDS to address those cases (and have the audit pass), which I think the contributors have pretty much agreed on an approach: custom mapping of the affected types where there's an Type 'discriminator' in IFC2x3, and presumably similar treatment in the audit tool.

[MatthiasWeise]

I agree that it sounds academic, but my point is:
If IFCFLOWTERMINAL + IFCAIRTERMINALTYPE is possible in IFC2x3, IFC4 etc. and has the same semantic meaning, then same IDS rule should lead to same checking result.

Implementation of model checking becomes more tricky then, but that is a consequence of IDS being agnostic from the IFC schema. Of course we can agree that this interpretation is for IFC2x3 only, but IDS becomes a little bit erratic then (in particular if we may introduce for IFC5 again).

To keep it simple, I am fine with proposed exception for IFC2x3, but please properly document in the specification (and ideally not only by a set of test cases ;-).

[andyward]

However, is this list really complete? I am missing for instance IfcActuator, and maybe more.

Will have to review - it's almost certainly not complete as it was a manual review

So I did some deeper analysis. This is the full list of IFC4 types implementors would need to handle if adopting the mapping approach. There's 57 in total

IfcFurniture                   : IfcFurnishingElement                with IfcFurnitureType
IfcSystemFurnitureElement      : IfcFurnishingElement                with IfcSystemFurnitureElementType
IfcActuator                    : IfcDistributionControlElement       with IfcActuatorType
IfcAlarm                       : IfcDistributionControlElement       with IfcAlarmType
IfcController                  : IfcDistributionControlElement       with IfcControllerType
IfcFlowInstrument              : IfcDistributionControlElement       with IfcFlowInstrumentType
IfcSensor                      : IfcDistributionControlElement       with IfcSensorType
IfcAirToAirHeatRecovery        : IfcEnergyConversionDevice           with IfcAirToAirHeatRecoveryType
IfcBoiler                      : IfcEnergyConversionDevice           with IfcBoilerType
IfcChiller                     : IfcEnergyConversionDevice           with IfcChillerType
IfcCoil                        : IfcEnergyConversionDevice           with IfcCoilType
IfcCondenser                   : IfcEnergyConversionDevice           with IfcCondenserType
IfcCooledBeam                  : IfcEnergyConversionDevice           with IfcCooledBeamType
IfcCoolingTower                : IfcEnergyConversionDevice           with IfcCoolingTowerType
IfcElectricGenerator           : IfcEnergyConversionDevice           with IfcElectricGeneratorType
IfcElectricMotor               : IfcEnergyConversionDevice           with IfcElectricMotorType
IfcEvaporativeCooler           : IfcEnergyConversionDevice           with IfcEvaporativeCoolerType
IfcEvaporator                  : IfcEnergyConversionDevice           with IfcEvaporatorType
IfcHeatExchanger               : IfcEnergyConversionDevice           with IfcHeatExchangerType
IfcHumidifier                  : IfcEnergyConversionDevice           with IfcHumidifierType
IfcMotorConnection             : IfcEnergyConversionDevice           with IfcMotorConnectionType
IfcTransformer                 : IfcEnergyConversionDevice           with IfcTransformerType
IfcTubeBundle                  : IfcEnergyConversionDevice           with IfcTubeBundleType
IfcUnitaryEquipment            : IfcEnergyConversionDevice           with IfcUnitaryEquipmentType
IfcAirTerminalBox              : IfcFlowController                   with IfcAirTerminalBoxType
IfcDamper                      : IfcFlowController                   with IfcDamperType
IfcElectricTimeControl         : IfcFlowController                   with IfcElectricTimeControlType
IfcFlowMeter                   : IfcFlowController                   with IfcFlowMeterType
IfcProtectiveDevice            : IfcFlowController                   with IfcProtectiveDeviceType
IfcSwitchingDevice             : IfcFlowController                   with IfcSwitchingDeviceType
IfcValve                       : IfcFlowController                   with IfcValveType
IfcCableCarrierFitting         : IfcFlowFitting                      with IfcCableCarrierFittingType
IfcDuctFitting                 : IfcFlowFitting                      with IfcDuctFittingType
IfcJunctionBox                 : IfcFlowFitting                      with IfcJunctionBoxType
IfcPipeFitting                 : IfcFlowFitting                      with IfcPipeFittingType
IfcCompressor                  : IfcFlowMovingDevice                 with IfcCompressorType
IfcFan                         : IfcFlowMovingDevice                 with IfcFanType
IfcPump                        : IfcFlowMovingDevice                 with IfcPumpType
IfcCableCarrierSegment         : IfcFlowSegment                      with IfcCableCarrierSegmentType
IfcCableSegment                : IfcFlowSegment                      with IfcCableSegmentType
IfcDuctSegment                 : IfcFlowSegment                      with IfcDuctSegmentType
IfcPipeSegment                 : IfcFlowSegment                      with IfcPipeSegmentType
IfcElectricFlowStorageDevice   : IfcFlowStorageDevice                with IfcElectricFlowStorageDeviceType
IfcTank                        : IfcFlowStorageDevice                with IfcTankType
IfcAirTerminal                 : IfcFlowTerminal                     with IfcAirTerminalType
IfcElectricAppliance           : IfcFlowTerminal                     with IfcElectricApplianceType
IfcFireSuppressionTerminal     : IfcFlowTerminal                     with IfcFireSuppressionTerminalType
IfcLamp                        : IfcFlowTerminal                     with IfcLampType
IfcLightFixture                : IfcFlowTerminal                     with IfcLightFixtureType
IfcOutlet                      : IfcFlowTerminal                     with IfcOutletType
IfcSanitaryTerminal            : IfcFlowTerminal                     with IfcSanitaryTerminalType
IfcSpaceHeater                 : IfcFlowTerminal                     with IfcSpaceHeaterType
IfcStackTerminal               : IfcFlowTerminal                     with IfcStackTerminalType
IfcWasteTerminal               : IfcFlowTerminal                     with IfcWasteTerminalType
IfcDuctSilencer                : IfcFlowTreatmentDevice              with IfcDuctSilencerType
IfcFilter                      : IfcFlowTreatmentDevice              with IfcFilterType
IfcVibrationIsolator           : IfcElementComponent                 with IfcVibrationIsolatorType

Xbim DotNet Fiddle code that generated this

Re: documentation. Happy to help document if we're agreed. We're just an implementor like many others but can put in a PR - presumably to the developer guide?

[MatthiasWeise]

Great, thank you for the list!
I guess the list of object types is in line with definitions in IFC2x3 (if not I would propose to exclude those entities from the look-up table).

Re: documentation.
Current agreement is for IFC2x3 only (due to missing occurrence entities for some type objects).
Such statement + link to the lookup table should be fine for the documentation.

[TLiebich]

Hi all - is there a solution for this issue for the upcoming IDS1.0 ? I would like to reiterate that this is a very critical issue, without a solution, validating IFC2x3 MEP models will be almost impossible with IDS1.0 (and given that the majority of IFC files are still IFC2x3, this would be a rather painful restriction).

I checked the documentation of the entity-facet, but could not find a resolution. Do I need to look somewhere else?