Reading mvdXML 1.2 documentation, section 7.2.5

<TemplateRule Parameters="PropertySetName[Value]='Pset_MaterialCommon' and SimplePropertyName[Value]='MassDensity' and NominalValue[Value] > '0.0'"/>

I believe that it should read NominalValue[Value] > 0.0, i.e. comparing to a real literal. If that is the case, correct all occurances.

With the requirement to have units available in mvdxml 1.2 we have added a reference to the IFC schema element IfcUnit. Unfortunately, this results in the generation of the entire IFC schema when generating the mvdxml schema just to access IfcUnit.

I would propose to rethink this approach and maintain the IFC and MVD specifications centrally, generating the subschema for mvdxml with just IfcUnit (namespace could also be ifcunit) from this central specification. This would mean that only the IfcUnit would be added to the classes required in mvdxml and would be in-sync with the IFC specification.

Reading Section 7.2.4 of mvdXML 1.2 documentation:

<!--A--><TemplateRules operator="or">
<!--1--> <TemplateRule Parameters="PsetName[Value]='Pset_BeamCommon' AND PropertyName[Value]='LoadBearing' AND Value[Value]=TRUE"/>
<!--B--> <TemplateRules operator="and">
<!--2-->   <TemplateRule Parameters="TypePsetName[Value]='Pset_BeamCommon' AND TypePropertyName[Value]='LoadBearing' AND TypeValue[Value]=TRUE"/>
<!--C-->   <TemplateRules operator="nor">
<!--3-->    <TemplateRule Parameters="PsetName[Value]='Pset_BeamCommon' AND PropertyName[Value]='LoadBearing' AND Value[Exists]=TRUE"/>
   </TemplateRules>
 </TemplateRules> 
</TemplateRules>

1. How should one interpret the construct above?

(1 and 2) nor 3
1 and (2 nor 3)

2. Where does A (or) get applied?

3. Also, IMHO, I'd put it differently (the way I understand it works in mvdXML 1.1):

<!--A--><TemplateRules operator="and">
<!--1--> <TemplateRule Parameters="PsetName[Value]='Pset_BeamCommon' AND PropertyName[Value]='LoadBearing' AND Value[Value]=TRUE"/>
<!--B--> <TemplateRules operator="nor">
<!--2-->   <TemplateRule Parameters="TypePsetName[Value]='Pset_BeamCommon' AND TypePropertyName[Value]='LoadBearing' AND TypeValue[Value]=TRUE"/>
<!--3-->   <TemplateRule Parameters="PsetName[Value]='Pset_BeamCommon' AND PropertyName[Value]='LoadBearing' AND Value[Exists]=TRUE"/>
 </TemplateRules> 
</TemplateRules>

Here, it is clearer, that the inner elements are the terms for the operators:

AND( 1 ; NOR( 2 ; 3 ))

Idea

An idea occurred to me when thinking about the SELF_TYPE token and where else a SELF reference could be useful. I could imagine the following scenario during certification (I can hardly imagine a scenario outside of that):

1. The file should contain one and only one element of type IFCANNOTATION.

How to specify this in the current state of the standard? If there is a solution, ignore the following proposal.

Proposal

Introduce a SELF_SIZE token to be used in the parameter strings. Usage example for the above statement (taking the example 7.2.3 from the documentation as a basis):

<ConceptRoot uuid="2aa33a62-6f0e-4d03-9f00-ba1796c62f1e" name="Ensure one IfcAnnotation" applicableRootEntity="IfcAnnotation">
  <Concepts>
    <Concept uuid="5fc09487-885f-4185-98e2-cb3ba2386087" name="Only one occurrance">
      <Template ref="6d70aadb-bd68-41b3-8b0f-0b56c5c09e86"/>
      <TemplateRule Parameters="SELF_SIZE=1"/>
    </Concept>
  </Concepts>
</ConceptRoot>

use something else than strings for rules

State

Documentation, chapter 4, grammar:

value : logical_literal | real_literal | regular_expression | string_literal;

Documentation, Table 19, Description of metric values:

SIZE: Indicates the size of a collection or STRING (value is an INTEGER).

Question

value cannot be type-safely an integer, although there is an int defined in the grammar. Thoughts?

Proposal

Expand value to include int_literal. I can prepare a PR if wished.

I can't seem to find them in the repository except for the plain text in the documentation PDF. I'd much appreciate having them as individual files in the repository.

Please add the license under which this work is published.

Given:

parameter
: simple_id | SELF;

SELF is not defined in the grammar. Proposal to be added in the lexer part of the grammar:

SELF : ( 'S' | 's' ) ( 'ELF' | 'elf' )

Reading mvdXML 1.2 documentation:

1. table of content: page number for section 7.2.6 is erroneous
2. section 0: inconsistent end of sentence punctuation for the bullet point
3. section 0, bullet point 3: typo funtionality
4. section 0, bullet point 5: there is a reference to 0 - probably erroneous
5. section 0: the reference to chapter 4 includes the word chapter, while the references to subsections 7.2.6, ..., do not. I'd propose to also include the word section for these.
6. section 4, ANTLR part: typo Mordernized

I did not read through the whole document yet, so this doesn't mean that I've cought them all.

boolean_expression
: ( NOT ) boolean_term (logical_interconnection ( NOT ) boolean_term)* ;
boolean_term
: ( leftside operator rightside ) | ( LPAREN boolean_expression RPAREN );

Propose to change to

boolean_expression
:  boolean_term (logical_interconnection boolean_term)* ;
boolean_term
: ( ( NOT )* leftside operator rightside ) | ( LPAREN boolean_expression RPAREN );

Now that it's possible to chain templates together, where an EntityRule on a ConceptTemplate can reference another ConceptTemplate, there needs to be a corresponding way to indicate parameter values for these "partial concept templates".

Propose adding a "References" element to TemplateRule which contains 0:N Concept objects (in parallel to EntityRule having References of 0:N ConceptTemplate). The Name of each Concept would identify the specific EntityRule by parameter ID.

[Alternatively, we could get by with the existing Concept.Subconcepts, however we would need a way to link each sub-concept to a particular TemplateRule and EntityRule (via parameter ID)].

This would then support unlimited nesting of chained concepts. Several examples:
a) Property Sets at the outer level, and individual properties at the inner level (though perhaps not a real use case since we already have IfcPropertySetTemplate and PSD format)
b) Defining constraints on objects within a parametric model view, where the first level may define IfcMetric linked to an IfcTable, and the next level specifying each IfcTableColumn.
c) Specifying units at IfcProject, where components of each conversion unit can be specified explicitly.

I've taken the current Draft9 of the schema (https://github.com/buildingSMART/mvdXML/blob/master/mvdXML1.2/xsd/mvdXML_V1-2_Draft9.xsd) and ran it through VisualStudio xsd utility. I get these errors (sorry for German language):

Microsoft (R) Xml Schemas/DataTypes support utility
[Microsoft (R) .NET Framework, Version 4.8.3928.0]
Copyright (C) Microsoft Corporation. All rights reserved.

Schema validation warning: Das Inhaltsmodell eines komplexen Typs muss aus 'annotation' (falls vorhanden) bestehen, gefolgt von Null oder einem der folgenden Werte: 'simpleContent', 'complexContent', 'group', 'choice', 'sequence' oder 'all', gefolgt von Null oder mehreren 'attribute' bzw. 'attributeGroup', gefolgt von Null oder einem 'anyAttribute'. Line 295, position 10.

Schema validation warning: Das Inhaltsmodell eines komplexen Typs muss aus 'annotation' (falls vorhanden) bestehen, gefolgt von Null oder einem der folgenden Werte: 'simpleContent', 'complexContent', 'group', 'choice', 'sequence' oder 'all', gefolgt von Null oder mehreren 'attribute' bzw. 'attributeGroup', gefolgt von Null oder einem 'anyAttribute'. Line 342, position 10.

Error: Schema .\mvdxml_v1.2.xsd could not be validated.

It seems that the order of <xs:attribute> and <xs:sequence> must be changed.

I've taken the current Draft9 of the schema (https://github.com/buildingSMART/mvdXML/blob/master/mvdXML1.2/xsd/mvdXML_V1-2_Draft9.xsd), with the fixes in #8, and ran it through VisualStudio xsd utility. I get this error (sorry for German language):

Schema validation warning: Verweis auf eine nicht deklarierte Modellgruppe 'https://standards.buildingsmart.org/IFC/RELEASE/IFC4/Add2TC1:IfcUnit'. Line 161, position 11.

It seems that this part makes problems:

Currently:

boolean_expression
: ( NOT ) boolean_term (logical_interconnection ( NOT ) boolean_term)* ;

Missing ? for the (NOT) part - or is it a must?

Proposal:

boolean_expression
: ( NOT )? boolean_term (logical_interconnection ( NOT )? boolean_term)* ;

For the next Coordination View 3.0 Certification (presumably for IFC 2x4), would it be possible to support and outline an 'MVD exchange requirement' for Groups/Blocks/Cells/Objects/Families/Components/Assemblies/Modules/etc. (exact name is software dependent) between BIM software? (For the sake of consolidation and discussion here, i'll call them #Groups)

Would like to support a workflow similar to the following...

• A BIM file, from Vendor X, contains 10 instances of #Group Z. →
• This BIM file is exported, via IFC, and in turn imported into Vendor Y's BIM file. →
• Within vendor Y's program, a user changes/modifies the definition of #group Z. This change is, in turn, propagated throughout the 10 instances of #Group Z , within vendor Y's file.

Not necessarily looking to save the parametric values of these #Groups yet, just static definitions at this point, would suffice. Want to keep it as simple as possible.

In an ideal world, it would be great to outline this proposed exchange schema as a new type of MVD, call it a #RoundTripMVD or #Bi-DirectionalMVD. I have a sense, however, that it would be easier incorporating this proposed exchange requirement in an existing MVD--Coordination View 3.0, for example...but would defer to others on this.

Related conversation, if interested. http://sourceforge.net/p/ifcexporter/discussion/general/thread/fad5b2f8/

From my understanding, would one use the following IFC entities to accomplish this?
--IfcMappedItem
http://www.buildingsmart-tech.org/ifc/IFC2x4/rc4/html/schema/ifcgeometryresource/lexical/ifcmappeditem.htm
--IfcGroup
http://www.buildingsmart-tech.org/ifc/IFC2x4/rc4/html/schema/ifckernel/lexical/ifcgroup.htm

Thanks Much, Ryan

I'm sure i'm missing a few, but provided the following for Reference...

• Revit (Families, Groups, Assembles)
• Microstations (Cells)
• Archicad (Objects, Modules)
• Vectorworks (Symbols)
• Tekla (Components)
• Sketchup (Components)

Main Readme links to http://www.buildingsmart-tech.org/specifications/mvd-overview/mvd-overview-summary - broken

Looking at the ANTLR grammar, the token NOT_EQUAL will never be found, since the ANTLR will match with NOT and then EQUAL. See priority rules.

Propose to move NOT_EQUAL before the definition of NOT in the lexer section.