fix-rel_enum

[atomczak]

[andyward]

Was this not by design? See https://github.com/buildingSMART/IDS/issues/278 - I feel like it should maybe have an underscore separator or similar so a) it looks less like an error b) will play more nicely with code generators using the enum.

[aothms]

I think also the space was by design so that it would match the XML list separator; so while now a hardcoded pair, it could be converted into an arbitrary list of enums without affecting the syntax. Can't comment on the tradeoffs though wrt codegen as mentioned by @andyward

[atomczak]

Someone reported this, and it looked like a mistake to me. Glad we have vigilant reviewers!

If that's supposed to solve "Wall that hosts a Window" (Wall that's partOf Window sounds worse), through wall <--IFCRELVOIDSELEMENT--> opening <--IFCRELFILLSELEMENT--> window, shouldn't we have more options in IDS1.1? For example, reverse "window that is hosted by a wall" or "wall that is voided by anything", or the @aothms example with IfcRelConnects.

<xs:enumeration value="IFCRELVOIDSELEMENT IFCRELFILLSELEMENT"/> 
<xs:enumeration value="IFCRELFILLSELEMENT"/> 
<xs:enumeration value="IFCRELVOIDSELEMENT"/> 
<xs:enumeration value="IFCRELFILLSELEMENT IFCRELVOIDSELEMENT"/> 
<xs:enumeration value="IFCRELCONNECTS"/>

I see it is a valid IDS file if the relation is not specified, so one can just say express "window that is in some way related to wall".

[NickNisbet]

<< if the relation is not specified, one can express "window that is in some way related to wall".>>

Argh! In a project model, everything is related to everything: window <-> … <-> project <-> … <-> wall

[atomczak]

Valid point @NickNisbet. I wonder why the relation name is optional: https://github.com/buildingSMART/IDS/blob/dd7b0689a7ddd6e62133d0eaba2f662f743eee9c/Schema/ids.xsd#L55C53-L55C71

[andyward]

Can't comment on the tradeoffs though wrt codegen as mentioned by @andyward

Regarding whitespace in an enum: It's more than code-gen - it just creates an extra bump in the road for implementors. E.g. I can see IDS OpenAPIs being a pain.

Basically if you're translating between an enum value expressed as a string (in IDS XML) and a 'typed' enum representation, any naïve conversion will fail if there's a space in the value since in most languages enumerations are intrinsically literals (which can't contain whitespace). E.g. Typescript, Java, C#, C++ etc.

Example: XIDS has this enum defined for PartOf relations:

public enum PartOfRelation
{
    Undefined,
    IfcRelAggregates,
    //...snipped
    IfcRelFillsElement_IfcRelVoidsElement   //  IFCRELFILLSELEMENT IFCRELVOIDSELEMENT would be invalid due to whitespace

}

When XIDS is mapping from a text value of 'IFCRELFILLSELEMENT IFCRELVOIDSELEMENT' we'd need to special case this value - in both directions.

[CBenghi]

everything is related to everything: window <-> … <-> project <-> … <-> wall

If the field is left empty it means to use all the relations valid in IDS, not all relationships in IFC.

@atomczak, the space in the enum is by design. I would reject this PR.