I have already mailed @mweise with some suggestions for one of the next minor versions of mvdxml (for example 1.2). But they all mostly boils down to different parts of the specification that needs to be much better specified. There are too many undocumented agreements in the format today, and there are also ambiguous things.
Product Geometry Colour in Reference View is one example of ambiguity. I think RV here describes that applying colours with StyledItem and SurfaceStyle is allowed only for SolidModels. So if you have tessellated geometry, colours should be applied with IndexedColourMap instead. But so far, the answer on the b-cert forum has been that it is probably allowed to use SurfaceStyle also for tessellated geometry because SurfaceStyle is part of the RV schema subset. My argument is that since no concept in RV describes that an IfcTessellatedItem (or any of its parent classes) can be styled by a SurfaceStyle, I think it should be considered disallowed. But I guess that wasn’t the intention of the RV authors.
For the next major version of MvdXML, I hope we can focus a little bit more on how MvdXML can be used in IFC authoring tools. So far, I think MvdXML has been designed with mostly documentation and validation in mind, and it is quite good and powerful for those purposes, I have to say! Especially with the additions you’ve proposed for MvdXML 1.2. But to efficiently use this information in an IFC export, I think some fundamental changes are needed.
I have the impression that one expects MvdXML to replace the need for manual user configuration in an IFC export. Today, the user often has a lot of technical options, like for example:
- Should building elements be exported as extruded solids (convenient for some kind of analysis and simulations) or as breps/tessellations (more precise geometry)?
- Should space boundaries be exported?
- Should space have geometry?
- Are boolean operations allowed?
- Are IfcOpeningElement allowed to have body geometry (for boolean clipping)?
And an MvdXML can probably answer most of these questions. But I think it is impossible to automatically detect all these things by programmatically parsing an MvdXML document. MvdXML is way too flexible and generic. To find out what kind of geometry is allowed for IfcWall, you have to parse and understand all the concepts on IfcWall. And how are you supposed to know by the MvdXML that in Reference View, IfcOpeningElement shall not have body geometry for clipping? You will need to manually interpret the human-readable documentation in the mvd to find out that, so there is no way the computer could automatically come to that conclusion.
One solution could perhaps be to split MvdXML into one/some official MvdXML base documents, which defines all needed concept templates. IFC authoring applications can then know about and specialize for these concept templates (by guid for example). So it is easy to recognize that if IfcOpeningElement uses concept template X, then you are not allowed to export body geometry for clipping.
Users and other third party companies should not be allowed to freely define new concepts (based on their custom concept templates). They should only have the possibility to use the official ones and set rules with parameters, thus they can create ER and validate data, but not come up with fundamentally new concepts.
Today’s approach, where we theoretically can get any new and fancy Concept Template from anyone, makes it impossible to automatically adapt the export so it produces files according to the given MvdXML. It is almost like giving the computer a grammar for a programming language and expect it (the computer) to produce a useful program with that grammar. That is not what grammar is made for, and this is the same feeling I get with MvdXML: it is made for (and works well for) defining (documenting) and validating (IFC) structures, but is very difficult to use in an IFC export situation.
