Industry Foundation Classes (IFC) is a data schema for representing buildings and associated activities for designing, constructing, and maintaining them. It may be encoded as XML (markup language commonly used for document-related data) or SPF (STEP Physical File commonly used for engineering-related data). The resulting data encoding may reside in a file or as part of Internet communication between desktop computers, servers, and mobile devices. Data may represent an entire project, a subset of information within a project, or changes to data within a project.
To support interoperability across hundreds of software applications, industry domains, and regions worldwide, IFC is designed to accommodate many different configurations and levels of detail. For example, a wall can be represented as a line (or curve) segment between two points, 3D geometry for visualization, and/or in construction detail (capturing individual studs, pipe fittings, wiring, etc.) along with engineering properties, scheduling and cost information. As different users of building data have different needs, and authors of building data will provide detail in different domains, there's a need to clarify which data is needed for a particular use. A Model View Definition provides a way to specifically indicate what data is needed. When parties are involved in a contract requiring data to be provided, a contract may indicate that data is to be delivered according to a specific Model View Definition and such data may be automatically validated to determine conformance.
Model View Definitions (MVDs) are encoded in a format called MVDXML, and define allowable values at particular attributes of particular data types. For example, an MVD may require that a wall provide a fire rating, a classification according to OmniClass Table 22, and information required for structural analysis such as elastic modulus of materials. In simple cases, such rules may define a single attribute on a single data type, while more complex cases may consist of graphs of objects and collections.
Various validation formats are already commonplace in the software industry for checking data conformance such as XML Schema Definition (XSD), EXPRESS (ISO 10303-11), Schematron, and validation frameworks within programming languages and tools (e.g. NUnit, JUnit). It is not the goal of MVDXML to replace such approaches, but rather automate them such that information requirements can be defined at a higher level, where downstream validation formats can be automatically generated, rather than relying on manual efforts which are error-prone and may become out-of-sync with specifications. However, validation is only one use for MVDXML; the higher-level nature of MVDXML enables many other uses as follows.
Software applications may make use of MVDXML either statically (designed to support a particular model view), or dynamically (designed to support any model view). Examples of dynamic functionality that may be supported include:
- Exporting data that is automatically filtered to include only data within a model view
- Downloading data from a server (where MVDXML essentially serves as a query language)
- Validating data to ensure it contains required information
- Prompting users to provide missing information
- Providing re-usable templates for product types, including parametric behaviors
- Importing and exporting tabular data with specified configurations of tables and columns
- Filtering application functionality to a subset within a model view (e.g. electrical domain)
- Providing attribute editing functionality for high-level concepts instead of low-level data.
While MVDXML is used within IFC4, it does not depend on IFC4; it may also be used with IFC2x3, earlier IFC releases, or entirely separate schemas.