Jeffrey W. Ouellette

I agree with @TLiebich points and believe there should always be an official bSI "baseline" implementation of most, if not all of the schema, in a practical use sense. This...

@pipauwel I'm trying to find the notes from that meeting. I believe Greg Schleusner has them. We need to get him connected...

@jmirtsch In this particularly egregious case of class hierarchy gone mad (the Building Services domain and its elements), I propose we work on simplifying the schema and separate the object...

@TLiebich Issue 1) I'm not sure I have control over. Do you wish to delete the Annex? Is that done though IfcDoc? issue 2) has been resolved by all traffic...

ahahahahahaahaha..... +1 I'm sure we can find others like this. Maybe "contacts" can be further generalized and enumerated rather than being a bunch of distinct classes.

@pipauwel I think this needs to be considered more carefully. By that I meant that we should more carefully evaluate what is an "attribute" of a class/object - something which...

Is this directly related to [https://github.com/buildingSMART/NextGen-IFC/issues/15](https://github.com/buildingSMART/NextGen-IFC/issues/15)?

@TLiebich we should probably get verification from vendors that IfcImageTexture is sufficient and that IfcBlobTexture is not needed. Even checking beyond the usual suspects and include Hypar, Pix3D and others.

While all previous "contraints" (references, dependencies) or the perceived arbitrary IA requirements should be reevaluated, I think that context for such constraints do matter and depend on the workflow. For...

This is an excellent example of something that needs further discussion and feedback from the ISG members... who will be meeting in a week’s time. A reminder that the other...