inherited children mesh nodes with same path

[michelangelo-acca]

In the domestic-hot-water.ifcx example, there are some nodes (i.e. PIP_20_001) which have a "Body" geometry node. PIP_20_001, however, also inherits from another node, which have children node with the same "Body" key...what happens in such cases?

• The Body on the direct node wins because is the "closest"
• The Body on the inherited node wins because is the "farthest"
• Both wins (i.e. display both) because their "full" path is different
• others ?

[aothms]

Indeed, not very clean, probably an artefact from the IFC4 file having RepresentationMaps on the IfcTypeProduct subtype and a Representation on the occurrence.

Curious how @tomvandig sees this, but I wouldn't look at it in a way that either of the Bodys win, but rather the same as composition on any other attribute on a certain path. In my previous implementation there was an approach based on topological sorting, which allows to trace the steps, I don't know exactly how it is implemented in the current implementation.

I would say:

1. /1a129af5-5ed9-5d03-b807-c4e32cfbb9c5: { attr: { body: ... } }
2. Broadcast (child) /1a129af5-5ed9-5d03-b807-c4e32cfbb9c5 to /52021154-adda-4091-a7fd-43e3554d6c7f/Body
3. .. simultaneously / same rank:
4. /8ff1ffd7-6c42-5c3a-a2a7-d0fa96622db0: { attr: { body: ... } }
5. Broadcast (child) /8ff1ffd7-6c42-5c3a-a2a7-d0fa96622db to /5b477df7-581a-4bab-b94c-7ab539a932d1/Body
6. ... then:
7. Broadcast (inherit) /52021154-adda-4091-a7fd-43e3554d6c7f/... to /5b477df7-581a-4bab-b94c-7ab539a932d1/... - That includes broadcasting /52021154-adda-4091-a7fd-43e3554d6c7f/Body to /5b477df7-581a-4bab-b94c-7ab539a932d1/Body where right side has higher strength because local definitions win from inherited ones.

So in other words, the Body representation on the occurrence and not the type object is what is visible, but if e.g the occurrence would define the points and the typeobject would define the indices, then both would simply end up side-by-side in the composed end-result. Or if one of the would be called Body, the other TypeBody, then both would be visible.

[michelangelo-acca]

Understood, was not aware that if there are attributes with the same key (i.e. Body in this case), if their values come from different sources, like for example on the occurrence we have "half" definition of the mesh, with only the points, and on the typeobject we have the other "half" definition of the mesh with only the indices (always with the same Body key), then the result of the composition would be the "full" mesh...was thinking that the occurrence half was overriding completely the typeobject half...good to know!

[aothms]

One consideration here, we have not really formally decided whether there is a difference to:

"attributes": {
        "bsi::ifc::presentation::diffuseColor": [
          0.5,
          0.5,
          0.5
        ],
        "bsi::ifc::presentation::opacity": 1,
      }

vs

"attributes": {
        "bsi::ifc::presentation": {
          "diffuseColor": [
            0.5,
            0.5,
            0.5
          ],
          "opacity": 1,
        }
      }

wrt to how to composition rules are applied. In the last case, is the presentation {} block composed atomically or is it composed equivalently to the above as two 'entries'?

cc @tomvandig @berlotti

I think the atomicity makes sense, i.e to for example not allow a "mesh" (point + indices) to be composed granularly on either the points or the indices, but only as a whole.

[michelangelo-acca]

Thanks for the clarification, some other considerations / questions on the topic:

• Never tought about the possible equivalence of "bsi::ifc::presentation::diffuseColor" vs "bsi::ifc::presentation" + "diffuseColor", cool!

• Ok for the mesh to be atomic, but in general, the rule for the composition is that "SameKey": { a: 1, b: 2 } on the occurrence, and "SameKey": { b: 3, c: 4 } on some inherited node => "SameKey": { a: 1, b: 2, c: 4 }, correct? Its not simply "child wins" or "inherited wins" (aka "SameKey": { a: 1, b: 2 } in the example)

• Curiosity, is this how USD works or is this bSI specific composition rule?

[tomvandig]

Hey!

This is a good discussion, and touches on a lot of stuff that we should really write down so that these things can be clear, especially the composition rules. I agree with @aothms ' explanation of the Body geometries.

I think atomicity should be enforced for two reasons: data should be valid even if you don't have all the layers, so pre-composition. "valid" here means: following the schema, and data should override on the level of the attribute, otherwise we can get into trouble when trying to override with different data and old keys stick around. These old keys may cause confusion in downstream parsing logic. So @michelangelo-acca one value always "wins", there's some rules that tell you which value wins, but there's no "unioning" the keys as in your example.

So, big fan of atomicity.

In regards to the presentation::diffusecolor or presentation + diffusecolor, I'm not 100% sure I understand. Is this only syntactic shorthand for attribute type names? If so that's nice, but not super useful? Or am I not seeing it.

Finally, I think the examples here are a bit confusing because a child is displayed as an attribute. The "body" is a child name, and so works atomically so set the child under that name. This is different from the atomic overrides of attributes.

[aothms]

I think atomicity should be enforced for two reasons: data should be valid even if you don't have all the layers, so pre-composition. "valid" here means: following the schema, and data should override on the level of the attribute, otherwise we can get into trouble when trying to override with different data and old keys stick around

This is a reasonable principle, but also has far stretching consequences. The mesh=points+indices example is relatively safe: hard to come up with a use-case where one wants override the points but doesn't know the indices. But more generally speaking, roles and responsibilities are very fluid in our industry and we need to be careful with any kind of coupling. This simply means:

• No or optional atomicity in schemas so end-users can be flexible in providing the data they know
• Atomicity in schemas and being very careful in coupling data into complex structures, i.e. using more side-by-side independent schemas. But this has implications: when there is no coupling or overarching structure, it is also harder to build richer semantics. For example the Shape Properties we have, let's say (simplistically) "a property set": 1. Shape = "Rect" | "Round". 2. (if round) Radius=real 3. (if rect) Width=real 4. (if rect) Height=real. Now, the solution to this is obviously richer types: Shape = {"type": "rect", width:1, height:2}. But previously there has been a lot of resistance against complex properties, because many tools cannot represent them or don't want to build UIs for them. And then 'coupling' between properties is a reasonable trade off between keeping properties primitive while also allowing dependent behaviour, but that is hard to realise when everything becomes loose independent fields to work around atomicity requirements.

[tomvandig]

@aothms I can follow the reasoning that the ownership boundary may lie inside of a component, but I don't understand the shape example. I think it should be possible to align ownership boundaries to components, so that the components can be atomic both in ownership and in data composition. I also think this is like a 'predict the future' thing, so instead we can try creating some workarounds:

• supply default values and a "fall through" value, where defaults are filled in if unknown, and a "fall-through" value allows you to override only what is specified, not all values. This may just be the default approach that solves the argument, but I'm not sure if it creates reasonable behavior for users. (e.g. isolated layer falls back to defaults, while composition does something different even though the isolated layer has priority)
• use references/children to create ownership splits. This would force us to create more intelligent references or meta-schemas to make sure that some kind of overarching structure is still in place.
• we make sure old keys don't stick around (this seems unlikely anyway because the attribute name is the type, so how would you get old keys?), and we validate only supplied fields pre-, and completely post-composition

Maybe we can find this middle ground somewhere.

[aothms]

The shape example is not particularly good, let's not focus on that, happy to see you agree there is some sort of tension between atomicity and composite ownership. For fall-through you mean kind of like CSS's inherit (maybe I make stupid claim, CSS is too difficult for me), so you could say: mesh: { "points": [1,2,3,4,5,6], "indices": {"inherit":1} }? You can express this also on the schema level (once we have unions). I don't really understand "we make sure old keys don't stick around". Also believe we should aim for some simple middle ground that allows some of this without increasing complexity, maybe even when more of the schemas are elaborated, these kind of issues disappear altogether.

[tomvandig]

Default/Fallthrough

Yes I think the CSS remark holds. But just to be clear, what I primarily want to achieve is a way where the data validation can always occur. This way if you parse an object to a schema you can always make it "fit" your typed internal object (be it database or struct or GPU buffer or whatever) without producing behavior that is based on guesses about what the data should be (e.g int is always 0). This means that, in a layer where not all keys of a schema are filled for a specific value, we can still do validation, querying, etc on that layer in isolation by somehow producing valid values for what is missing.

Those values can be default values on the schema (bsi::fire_rating: { type: string, default: "R30"} + inherit / missing key), or they can be values in the sense of: IF there is no other value specified, use this value. This is what I mean with fall-through, not sure if that's a good term.

Caveat

Its good to mention though that this is not all-powerful, ownership splits resolved like this don't mean we get arbitrary boundaries inside the component. For instance, we cannot easily have ownership splits inside an array, as its not clear how to merge different values during composition. It just means we push atomicity one level "down" from component atomicity to key-atomicity. If this fixes real problems, then great. But the further we go the more complexity we invite, as always. Earlier, we decided this was OK and we can present differing opinions on this level as conflicts to be resolved by the owner of the component/entity.

Old keys sticking around

What would be very unfortunate, is a scenario where two layers talking about the same type but a field is optional. One layer may be highest priority with the intent to overwrite with its value, but simply because a field is optional and the composition is not atomic, we end up with the optional value being filled in after composition, even though the highest-priority layer does not set the optional parameter. At the same time, it makes a ton of sense to present "missing optional field" as "missing object key" to be able to do easy schema upgrades (add optional field => old data is still valid for the new schema). I can see something similar happening when doing diffs, where the intention should really be: "this is the new value", not "the new value is the current value unioned with the new value".

Maybe there's something simple we can do to fix this?

My guess would be: just like the default/fall through value, we can fix this behavior by really making a difference between "I don't care about these keys" and "I want to explicitly set this optional key to 'empty'".

My additional fear was that this would create havoc when mixing types. However, this makes no sense, as the keys are the schema name, so we will only ever see this union for objects following the same schema.