Currently, 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). buildingSMART is working towards a solution where these 'out of the box' technologies can work on IFC.
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. 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. New technologies, and the decision to maintain IFC in UML (XMI) is creating a situation to reconsider mvdXML and look at generic technologies to create Exchange Information Requirement definitions.
Documentation for the current version of mvdXML (1.1) is available as a PDF, as well as an XSD.
An example of using mvdXML for documentation can be found here. Refer to chapter 7.1 of the PDF documentation.
Future of mvdXML
The direction set out in the 2020 buildingSMART Technical Roadmap has big implications on the use of mvdXML. The future of defining a base for IFC Software implementations will be worked on using industry standards and predictable quality checking frameworks.