Compatibility investigations as part of ISO acceptance process

[aothms]

Below you can work in progress on the investigation of compatibility on STEP physical file (ISO 10303-21) level (*.ifc) and general consistency of the EXPRESS (ISO 10303-11) models between ISO 16739-1:2018 (IFC4) and NWI for IFC4.3.

Slides

1/53

2/53

3/53

4/53

5/53

6/53

7/53

8/53

9/53

10/53

11/53

12/53

13/53

14/53

15/53

16/53

17/53

18/53

19/53

20/53

21/53

22/53

23/53

24/53

25/53

26/53

27/53

28/53

29/53

30/53

31/53

32/53

33/53

34/53

35/53

36/53

37/53

38/53

39/53

40/53

41/53

42/53

43/53

44/53

45/53

46/53

47/53

48/53

49/53

50/53

51/53

52/53

53/53

Outline

1

compatibility investigations as part of ISO acceptance process

Compatibility on STEP physical file (ISO 10303-21) level (*.ifc) and general consistency of the EXPRESS (ISO 10303-11) models between ISO 16739-1:2018 (IFC4) and NWI for IFC4.3

2

Approach

AFNOR conducted a systematic analysis of the compatibility of ISO/NWI 16739-1(rev.) with ISO 16739-1:2018, based on the change log

JWG 12 (T. Liebich) compared the ISO/NWI 16739-1(rev.) EXPRESS model with the ISO 16739-1:2018 EXPRESS model

Both identified some incompatibilities including errors brought up by running an EXPRESS parser

ISO TC59/SC 13/JWG 12 launched an editorial group to handle these incompatibilities and improve the project standard before starting the DIS process in ISO to avoid negative votes or technical comments

This document analyses these issues and defines the solutions chosen

3

General notes on compatibility

There are two ways of compatibility regarding data schemas

Backward compatibility : a data file, written against the previous release of the data schema shall still be readable by an application compiled against the schema of the new release

Forward compatibility : a data file, written against the new release of the data schema shall still be readable by an application compiled against the schema of the previous release

In IFC history only backward compatibility had been considered

4

Context on compatibility

The common understanding of “backward compatibility” between two data schemas in EXPRESS being an international standard is:

A data file, written against the previous release of the standard (here an *.ifc file based on ISO 16739-1:2018 (IFC4.0.2.1)) shall still be readable by an application supporting the new version (IFC4.3)

Some reinterpretation and permissiveness may be acceptable (see next slide)

5

Example for such compatibility assessment

Such an assessment had been made before comparing IFC4 and IFC2x3 CV-subset

It includes criteria on what changes and reinterpretations are deemed acceptable or not acceptable

It is used as a reference, while some specifics are still discussed within ISO TC59/SC 12/JWG 12

Compatibility of property sets has not been rigorously assessed because (by means of the mechanism of property names as literal values in the exchange) it does not affect schema compatibility

6

Meaning of deprecation

The JWG 12 team discussed and proposed a more common definition:

“this definition will be removed in a future major release of this standard”

and add further normative text to explain the intended meaning

Complying interpreters shall still be able to import deprecated definitions

Complying interpreters shall consider to modify export using the proposed alternative definitions instead of the deprecated ones

7

IfcAxis{1,2}Placement{2D,3D} > where_rules > LocationIsCP

(row 12,13,14)

8

IfcBuilding deprecated attributes

(row 24)

bSI: Editorial action on definition of deprecation under consideration

9

IfcBuildingSystem > where_rules > CorrectPredefinedType

(row 29)

“New where_rule on a deprecated entity?”

bSI: CorrectPredefinedType and CorrectTypeAssigned rules are now automatically generated by the authoring system so this is not a “new rule” per se, but just an expression of the modelling method of IFC.

10

IfcBuildingSystem > deprecated > Changed from False to True

(row 30)

“How do we manage compatibility?”

bSI: Deprecated by infra/rail team. 4.3 team to investigate.

✓ IfcBuiltSystem introduced. Clarify in docs.

11

IfcComplexProperty > deprecated > Changed from False to True

(row 47)

Dependencies between properties

“This entity is used at least by prEN 17549-2. No solid alternative.”

bSI: Usage of CP in 17549 seem speculative. To discuss.

✓ Within bSI also not consensus. Reverted.

12

IfcMaterialClassificationRelationship > deprecated > Changed from True to False

(row 133)

“No longer deprecated?”

✓ Undeprecation was accident in 4.1. Redeprecated.

13

IfcMaterialRelationship > attributes > Expression name > Changed from Expression to MaterialExpression

(row 134)

bSI: Result of harmonization effort:

Attribute/property with:

same Range+Semantics ↔ same name

different Range/Semantics ↔ different name

✓ change by purpose – weight clear semantic over minor change in schema.

14

IfcObjectPlacement > attributes > PlacementRelTo

(row 144, 291)

PlacementRelTo attribute moved from IfcLocalPlacement to its supertype IfcObjectPlacement, also a supertype of this entity. That means that for correct global positioning, the IfcGridPlacement will reference (a) the ObjectPlacement of the IfcGrid by means of IfcObjectPlacement.PlacementRelTo and (b) the pair of IfcGridAxis contained in that same grid by means of the IfcVirtualGridIntersection.

bSI: For uniformity of Linear and Grid. This is a backwards incompatible change in schema and semantics.

Potential arguments to keep the change:

IfcGridPlacement is not part of any official MVD or derived standard, highly likely that it is not used in interfaces today

The improvement to unify the relative placement over all subtypes (local, grid, linear) is a strong improvement – this should take priority here

TODO: improve documentation by highlighting the consequences of the change

15

Grid placement in IFC4

16

Normalised grid placement in IFC4.3

17

IfcObjectPlacement > inverses > ReferencedByPlacements > definition

(row 145)

Changed from

SET OF [0:?] IfcLocalPlacement FOR PlacementRelTo

to

SET OF [0:?] IfcObjectPlacement FOR PlacementRelTo

bSI: Symmetric inverse highly preferrable, necessary for Grid and Linear as they are relative placements also. No compatibility impact.

18

IfcRelConnectsPortToElement > deprecated > Changed from False to True

(row 197)

Ref: https://forums.buildingsmart.org/t/ifcrelconnectsporttoelement/2510

bSI: This was specific to “dynamic ports” and is obsolete

-> TODO: add an IFC4.3.0.0 deprecation note stating that the entity is now deprecated and IfcRelNests should be used for all parts, including dynamically connected ports.

19

IfcRelCoversSpaces > deprecated > Changed from True to False

(row 198)

✓ Undeprecation was accident in 4.1. Redeprecated.

20

IfcRelInterferesElements > attributes > ImpliedOrder > definition

(row 199)

bSI: Generalized definition to non-geometry oriented interferences for infra.

21

IfcRelInterferesElements > attributes > InterferenceSpace

22

IfcRelServicesBuildings > deprecated > Changed from False to True

(row 208)

bSI: To investigate. Not sure why deprecated by rail/infra team. Editorial action might be required.

TL: IfcRelServicesBuildings is an anomaly. Not just buildings. Generalized.

✓ New entity to use is documented.

23

IfcTelecomAddress > deprecated

(row 253)

This entity is deprecated. Use Pset_Address instead, which is applicable to IfcActor, IfcBuilding and IfcSite.

“Change an IFC entity. Not OK”

bSI: Editorial action on definition of deprecation under consideration

AFNOR: How about: IfcPerson, IfcOrganization.

TK: See Pset_Addres <- Rel -> IfcActor -> IfcPerson on next slide

TODO: Deprecate IfcActor.Addresses, IfcPerson.Addresses

25

IfcTransformer > where_rules > CorrectTypeAssigned definition

(row 262)

Changed from

(sizeof(IsTypedBy) = 0) or (ifctranformertype in typeof(self\IfcObject.IsTypedBy[1].RelatingType))

to

(sizeof(IsTypedBy) = 0) or (ifctransformertype in typeof(self\IfcObject.IsTypedBy[1].RelatingType))

bSI: Typographic error addressed

26

IfcTrapeziumProfileDef > deprecated > Changed from False to True

(row 267)

“Deprecated, Other Class can be used”

Ref: https://forums.buildingsmart.org/t/how-are-the-sides-of-ifctrapeziumprofiledefs-bounding-box-calculated-in-most-implementations/2945/14

bSI: Ambiguity and confusion in definition existed. Not worth the effort to fix as recommended by vendors.

Still to be done: add IFC4.3.0.0 deprecation note: Use IfcArbitraryClosedProfileDef instead

27

IfcTriangulatedFaceSet > attributes > Closed

(row 268)

“attribute 'closed' is now inherated from IfcTesselatedFaceSet.Position of attribute 'closed' has moved (from position '3' to position ‘2’). Not OK”

✓ Was suggestion from an implementer. Reverted.

28

IfcVoidingFeature > where_rules > CorrectPredefinedType

(row 276)

“New rule. Seems a duplicate to rule HasObjectType so why adding a duplicate rule? Is it really a duplicate?”

Applies to IfcSurfaceFeature, IfcVoidingFeature, IfcRailway, IfcRoad, IfcStructuralAnalysisModel

✓ Duplicate (compatible) rule removed. No compatibility impact.

29

IfcCivilElement(Type) > deprecated > Changed from False to True

(row 40, 41)

“Deprecated but without any explanation, what is the entity to use now? Maybe related to the new IFC4.3 extension for infra that already contains Civil entities”

Suggestion TK:

TODO: [IFC4.3.0.0 Deprecation] Usage of a generic element for civil engineering works is no longer desirable with specific civil elements now provided as subtypes of IfcBuiltElement, IfcEarthworksElement, IfcFacility and IfcGeotechnicalElement.

30

IfcClassification > attributes > Location > name > Changed from Location to Specification

(row 42)

“Changing the name of the Location attributes to Specification in keeping the same position. Missing attribute Description”

TK: ISO (23386?) 12006-3 compatibility

✓ Description provided.

31

IfcElectricDistributionBoard(Type) > deprecated > Changed from False to True

(row 81, 82)

-> “No alternative proposed in the changelog” Not OK

TK: New resource IfcDistributionBoard. Somewhat questionable I must say as renames through deprecation are painful.

ALL: Agree on sentiment (especially since there is no formal tracking of the rename operation) but agree to state the alternative in the docs as a solution.

TODO: Add explanation

32

IfcIndexedPolyCurve > attributes > SelfIntersect > is_optional > Changed from True to False

(row 118)

“Attribute changed from optional to mandatory ie. Instead of omitting the attribute you need to give it the value 'UNKNOWN'. This generates an incompatibility with ISO 16739-1:2018”

TK: This unifies all definitions of SelfIntersect as (non-optional) IfcLogical. For types: IfcBSplineCurve, IfcBSplineSurface, IfcCompositeCurve, IfcIndexedPolyCurve, IfcOffsetCurve2D, IfcOffsetCurve3D

Ternary logic in the form of {$, .T., .F.} (optional bool) is semantically equivalent to {.U., .T., .F.} (logical)

TK: can be dealt with in software?

TL: More unified, harmonized definition takes priority of minimal backwards compatibility

TL: Heavily used, the benefit is minimal

TODO: Revert

33

IfcPostalAddress > deprecated > Changed from False to True

(row 169)

"OK, as use of ""Pset_Address"" covers ""IfcPostalAddress"" fieldsHow are we supposed to handle IfcPerson and IfcOrganization“

TK: Pset_Address covers both Postal- and TelecomAddress. Outdated due to fields like PagerNumber (entities painful to update due to compatibility). More discoverable due to focus on psets in end user tools. See slide 18 for usage in case of Person and Organization by embellishing with IfcActor.

34

IfcCountMeasure > Type changed from NUMBER to INTEGER

(row 290)

TK: NUMBER is a conceptual supertype in express of both INTEGER and REAL. Not well supported in software and didn’t meet domain expert expectations. Compatibility effects are minimal.

ALL: Accept the change.

TODO: Make sure properly stated

35

IfcBuildingElementProxyTypeEnum

(row 291)

'PROVISIONFORVOID' and

'PROVISIONFORSPACE’

TK: Breaking changes in enumerations are seen as less severe. In this case deletion was favoured over deprecation+duplication (in IfcVirtualElement).

Note already provided in docs: [IFC4.3.0.0-CHANGE] IfcBuildingElementProxy should no longer be used as spatial placeholders or provisions. Use IfcVirtualElement instead.

ALL: Deprecation would be preferable and more consistent.

TODO: deletion -> deprecation

36

IfcDoorTypeOperationEnum

(row 292)

DOUBLE_DOOR_xyz changed to DOUBLE_PANEL_xyz

REVOLVING changed to REVOLVING_HORIZONTAL

✓ Reverted. The compatibility risk outweighs the improved semantic clarity.

TK: DOUBLE_PANEL_LIFTING_VERTICAL was newly added, for consistency I also changed this to DOOR. Objections?

TODO: The new items do not have definitions. DOUBLE_PANEL_LIFTING_VERTICAL LIFTING_HORIZONTAL LIFTING_VERTICAL_LEFT LIFTING_VERTICAL_RIGHT REVOLVING_VERTICAL

37

IfcNullStyle, IfcPresentationStyleSelect, IfcStyleAssignmentSelect

(row 293, 294, 296)

TK: Were deprecated in IFC4. This creates a much more sane assignment of styles. See next slide.

The only question is whether IfcStyledItem.Styles should be cardinality [0:?] to account for the deletion/deprecation of IfcNullStyle. I don’t see a strong reason for it, because in case of no styling, the IfcStyledItem itself can be omitted.

Note: IfcNullStyle was not deprecated in ISO version (=4.0.2.0 not 4.0.2.1)

39

IfcStrippedOptional deleted

(row 295)

TL: IfcStrippedOptional is a mechanism for creating schema subsets (MVD) that probably should have not made it into the main schema.

TODO: Decision  Proposal – delete it (it was an unused type definition in ISO 16739-1:2018 by mistake)

TODO: Bring back. Type shall only be used in conjunction with partial schema production. It’s used to replace entity attribute types to keep the attribute order in tact.

40

Change already covered.

TODO: Add underlying type changes to changelog

41

✓ IfcBuildingSystemTypeEnum reverted to IFC4 state.

Note that this is potentially painful for 4X2 implementers, but this is a withdrawn standard.

42

✓ Added back REDUCER and add deprecation notice to use TRANSITION

43

✓ Deleted

✓ Where rules updated

Question TK: IFCSHAREDBLDGELEMENTS.IFCDOORTYPE How does that work? Should modular schema prefixes be translated to full schema names?

TL: Pre IFC4.3 EXPRESS modelling was done by short form and translated to long form for final publishing, so:

TODO: so use “IFC4x3.IFCDOORTYPE” in rules

44

TODO: Specify in docs fact that IfcBorehole and IfcGeo- are anomalies

TODO: Mountable to Pset_KerbCommon, Add predefined type (Agreed already in https://github.com/buildingSMART/IFC4.3.x-development/issues/435)

45

ObjectType attribute definition

46

✓ Added

47

TODO: Discuss internally

TL: Function + derived attribute can be added in TC.

TODO: Remove function and derived attribute

48

About IfcRevolvedAreaSolid: Some wild guess. PFJ to check with experts: (‘IFC4X3.IFCCARTESIANPOINT’ in TYPEOF(Axis.Location)) AND (Axis.Location\IfcCartesianPoint.Coordinates[3] = 0.0)

TL: IfcPoint.Dim

• remove Dim on

IfcPoint subtypes

49

TL: Dim needs to be promoted to IfcSegment

TK: Does that mean ParentCurve as well? Which is possible if we also move SameSense up (we could even make it derived=TRUE)? Essentially IfcSegment can be eliminated and IfcCurveSegment becomes a pure subtype, this is beneficial for compatibility, because IfcCompositeCurve.Segments remains the same type.

TODO: Accommodate with where rule changes

50

TL: there is no change log at IfcCompositeCurve (showing the changes attribute Segments)

TK:

TK: Not collapse by default

TL: the figures of the parameterization from ISO 10303-42 are missing

TODO known issue https://github.com/buildingSMART/IFC4.3.x-development/issues/501

51

SM: why removal of IfcWindowStyle did not affect IfcWindowStyleOperationEnum?

TK: Is affected:

✓ TK to programatically assess orphaned type defs

52

IfcBearingTypeDisplacementEnum

Discovered as orphaned enum (seems to have never been referenced, introduced in 4x2)

Not a concern for compatibility

TODO: Decision pending

53

Unused functions (such as IfcVectorSum)

Not a concern for compatibility