Hi,
I’m working on parsing the ReferenceView MvdXML document, and I have some problems and annoyances that I want to share. I really hope they will be addressed in the future.
Problem 1:
Some of the expressions in TemplateRule[@Parameters] does not follow the grammar. Here two examples:
<TemplateRule Description="Assignment to the building, where the building storey is a part of." Parameters="Spatial Composite=IfcBuilding;" />
<TemplateRule Description="Assignment to another building storey, e.g. if this building storey is a
partial storey that refer to another storey." Parameters="Spatial Composite=IfcBuildingStorey;" />
These two are from the ConceptRoot for IfcBuilding. First of all they are invalid and is not possible to parse with the grammar from the MvdXML spec. (the space in “Spatial Composite” is the problem, this is just free text…?) And the second problem is that even if they were valid, there are no RuleID named “Spatial Composite” in the referenced ConceptTemplate. I think there are around 17 other similar expressions in the official ReferenceView mvd.
We have no other choice than to just leave these as invalid and not evaluate them in automatic validation. Would it be possible to bugfix this in the current version of ReferenceView, or do we have to wait for a next version?
Problem 2:
While the expressions in all ConceptTemplates looks modern and fine, the expressions in the ModelView (in TemplateRule[@Parameters]) are of an old style. Here are three examples:
PsetName=Pset_ProtectiveDeviceTrippingFunctionGCurve;
RelatedObjects=IfcRampFlight
Identifier=FootPrint;Type=GeometricCurveSet;Items=IfcGeometricCurveSet
In more modern syntax (aka mvdxml 1.1), these could have been written like this:
PsetName[Value]=’Pset_ProtectiveDeviceTrippingFunctionGCurve’
RelatedObjects[Type]=’IfcRampFlight’
Identifier[Value]=’FootPrint’ AND Type[Value]=’GeometricCurveSet’ AND Items[Type]=’IfcGeometricCurveSet’
With the modern syntax, these are quite self-explanatory both for human and computer. But the spec doesn’t say anything about how the old syntax should be evaluated (though it is valid). Would it be safe to transform them from this old form:
PsetName=Pset_ProtectiveDeviceTrippingFunctionGCurve
Into:
(PsetName[Value]=’Pset_ProtectiveDeviceTrippingFunctionGCurve’ OR PsetName[Type]=’Pset_ProtectiveDeviceTrippingFunctionGCuvrve’)
? Or is there a better strategy for evaluating these expressions?
This means that all boolean terms that goes like {simpleid}{operator}{simpleid} can be detected and transformed into
“(“{simpleid}[Value]{operator}{secondOperandAsString}”OR”{simpleid}[Type]{operator}{secondOperandAsString}”)”
But it would be very good if this was documented somewhere (as an implementers agreement maybe?), because this will add some restrictions on how the rules can be written.
Problem 3:
The mvdxml for ReferenceView isn’t valid according to the mvdxml xsd schema. One example is these lines:
<ConceptTemplate uuid="efca410b-49d4-4e76-a6c9-18f258465d5c" status="sample" applicableSchema="IFC4" applicableEntity="IfcActuator" />
<ConceptTemplate uuid="13c1f742-eb08-4a19-ab9f-b359f97c7d58" status="sample" applicableSchema="IFC4" applicableEntity="IfcAirTerminalBox" />
<ConceptTemplate uuid="e9f4c678-69f3-4ff9-ac64-0a52cc964bbc" status="sample" applicableSchema="IFC4" applicableEntity="IfcAirTerminal" />
<ConceptTemplate uuid="6dd5e667-f86f-4e0a-8fa4-806e58785fc7" status="sample" applicableSchema="IFC4" applicableEntity="IfcAirToAirHeatRecovery" />
<ConceptTemplate uuid="d4fba30d-3f7c-40c2-ab05-e6c72a28d416" status="sample" applicableSchema="IFC4" applicableEntity="IfcAlarm" />
[123 more lines like this…]
The @name attribute is required on ConceptTemplate, but none of these have it. There are probably also other examples, but I had to give up strict parsing and also had to add additional safety tests in the code so it doesn’t fail on missing attributes.
Before publishing a new version, the mvdxml document should at least be runned through an xml schema validator. And I think it would also be very wise to run some validation on the rule expressions as well. It isn’t that hard to write a parser for the expressions, it could probably be done with a regular expression.
If this is the quality of mvdxml documents generated from IfcDoc, I expect all other third party mvds to be of the same poor quality, so I have to be very careful when reading the data. The IfcDoc should instead ensure perfect quality of the generated mvds.
Problem 4:
The mvdxml namespace url points to http://buildingsmart-tech.org/mvd/XML/1.1, but BuildingSMART has moved all these documents to a different domain: technical.buildingsmart.org. They have brought up the old domain again, but the old urls aren’t redirecting to the new locations for the schemas. I think that should be done so that standard XML readers/editors can validate the files without any special configuration.
Minor problem 5:
I don’t think the grammar allows the expressions to end with semicolon. If the support for those legacy semicolons (interpreted as AND operators) are to be kept in future versions of mvdxml, then maybe the grammar should be updated to explicitly allow a semicolon on the end as well, because I see many rules in the ReferenceView are ending with semicolon.