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.
Since the original publication of mvdXML 1.0 in 2013 the interest in mvdXML usage has moved beyond simply documenting MVDs in a neutral, machine-readable way to also include validation. This means the content of an IFC file, created with a specific MVD, can be checked against the mvdXML for general correct structure and inclusion (or exclusion) of concepts and properties, as well as verifying the specific values of properties as determined in the Exchange Requirements of the MVD. For example, an mvdXML file for a spatial validation analysis can include the actual occupancy values for identified spaces/rooms in an IFC file.
The previous mvdXML 1.0 had several limitations in adding such data validation rules. The main focus of mvdXML 1.1, beside bug fixing and general improvements, had been in enhancing the validation part. In addition, the documentation and the examples have been greatly improved to ease the understanding of the scope and methodology behind mvdXML.
An example of using mvdXML for documentation can be found here. Refer to chapter 7.1 of the PDF documentation.
An example of using mvdXML for validating and IFC file can he found here. Refer to chapter 7.2 of the PDF documentation.