"late binding" better words

[I-Sokolov]

I do not like "late binding" term. It confuses me with late binding programming paradigm. Can we look for better one?

Some suggestions

• dynamic classing, soft classing vs
• schema classing, hardcoded classing

[berlotti]

Agree the term can be confusing. We tend to use 'early binding definitions for late binding implementation' lately. What do you think of that?

[I-Sokolov]

Hmm... Leon it sounds like wordplay for me and even more confusing to me:) Did I understand it correct - is the intention to make smaller number of classes in the IFC schema and apply more detailed information by classification reference, type object, properties etc?

[TLiebich]

Hi Igor - a while ago I called it "reference data" compared to "schema", where:

• schema is a definition of a data structure with associated meaning (semantics) that exists on compile time
• reference data is semantic data, referenced from the data structure defined by the schema, that adds additional meaning on run time.

not sure whether it is clearer, but other standardisation initiatives have used such terms

and yes, the purpose is as you describe - move the taxonomy of elements out of the schema into an external definition, that is still part of the IFC standard, can be parsed, but can have a different (and more frequent) release strategy, similar to property sets.

[hlg]

I think it would be good to keep implementation details out of the schema, also in terms of terminology. In my view implementers should have the freedom to choose when and how to handle which parts of the schema definition. Of course, it seems natural to handle frequently changing parts at run time and slowly changing at compile time. But implementers may want to handle everything at run time or everything at compile time. There are approaches to software development that blur the boundary between compile and runtime, e.g. by code generation. Shouldn't all of those be supported and possible?

[hlg]

In terms of terminology, "InstanceSpecification" as defined in UML (not to be confused with the actual instance, the object) may be what we are looking for. I have to better understand the "late bound" idea to confirm.

[aothms]

Some ideas:

Element kinds Type labels Stereotypes (also from UML)

I don't think it matters a lot what we call it. Choose something that doesn't have a strong existing meaning in our domain and be consistent. @TLiebich reference data to me has the risk of sounding a bit supplemental, non-normative.