Software developers

Overview

The purpose of the IFC Model Definition, i.e. the IFC schema and its documentation, is to define a data model that covers the whole lifecycle of the built environment for all actors involved. It is logical that any software product (except middleware) only deals with a subset of the full IFC Model Definition. MVD (Model View Definition) is the tool for defining model subsets that are relevant for the data exchange between specific application types. The goal is that software implementers are only confronted with the parts of the IFC Model Definition relevant to them.

However, defining a subset of IFC is not enough. Because of its wide scope and inclusive nature IFC does not provide detailed information about how it should be used in specific cases. Making such decisions about the use of IFC has been left to IFC implementers. These decisions are called implementer's agreements and they are documented as part of MVDs. When implementing IFC it is crucial that all relevant implementer's agreements are respected. If you are interested in taking part in defining implementer's agreements for IFC, please visit the Technical authors section.

Finally, certification for IFC implementations is done using MVD, i.e. software applications are certified for one or more MVDs. Certification checks that implementations cover the scope of an MVD and all relevant implementer's agreements have been respected.

One way for one thing -policy

The basic process of creating standards is to commonly agree on one way of doing something. In the case of IFC implementations the first step is to use the standard IFC schema as the basis for data exchange. For clarity and consistency IFC implementations should always fully comply with the IFC schema, even if this sometimes seems to make little sense. In addition to using the IFC schema implementers must often agree on how to apply the IFC schema in a specific case, i.e. make implementer's agreements. The 'one way for one thing' -policy applies to these implementer's agreements. It contains two parts; defining the thing and defining the way of doing the thing.

In MVD the 'things' are called concepts. For example 'Metric Project Units' is a concept, which defines how the units of a project are exchanged using the metric (SI) unit system. Another concept is 'Imperial Project Units'. The concepts used in a specific exchange are determined by the purpose of that exchange. Most often defining the concepts and their scope is straight forward, but there are usually some details to be worked out. For example if the unit system should always be 'pure' or if mixing unit systems in the same project is allowed. It could also be considered if metric length units in the exchange can be standardized to millimeters, or if this would in some cases lead to unacceptable rounding errors.

The way of doing the thing is a slightly more complex issue. As a basic rule allowing more than one way for doing exactly the same thing does not provide any value for data exchange. On the contrary, it increases the implementation effort and raises the probability of bugs and interoperability problems. From the interoperability viewpoint it is much more important to agree on one way that works, than to find the best or optimal way. From the implementation viewpoint software developers however tend to look after their own interest. Each software has its own internal model and the task of IFC implementation is basically creating a mapping between the internal model and the IFC model. Because internal models are different, one way of doing a thing might be easier to implement in one software than in another. This is the case for example for the extrusion direction of a wall geometry, which could be along the wall axis, upwards or perpendicular to the face of the wall.

The 'one way for one thing' -policy says, that implementers must always agree on one way for doing any specific thing. After the agreement has been made all implementers are required to respect the agreement. The best way to influence the agreements is to participate actively in their definition.