├── README.md
├── mvdXML1.1
├── grammar
│ └── mvdXMLv1_1.g
├── mvdXML1-1_WorkingDocument.docx
├── xml
│ ├── Example-CV100.xml
│ ├── Example-CV104.xml
│ ├── Example-CV106.xml
│ ├── mvdXMLv1-1_example1.xml
│ ├── mvdXMLv1-1_example2.xml
│ ├── mvdXMLv1-1_example3.xml
│ ├── mvdXMLv1-1_example4.xml
│ └── mvdXMLv1-1_example5.xml
└── xsd
│ └── mvdXML_V1-1_draft.xsd
└── mvdXML1.2
├── grammar
├── ANTLR
│ └── mvdXMLv1_2.g
└── mvdXMLv1_2.g
├── mvdXML_V1-2-Draft9.pdf
└── xsd
├── mvdXML_V1-2_Draft9.xsd
├── mvdXML_V1.2.xsd
├── mvdXML_V1.2_draft3.xsd
└── mvdXML_V1.2_draft8.xsd
/README.md:
--------------------------------------------------------------------------------
1 | mvdXML
2 | =================
3 |
4 | With the MVD policy and IDS in place, the mvdXML is only used as internal structure for Software Certification.
5 | mvdXML 1.2 is not a formal buildingSMART standard (yet) but is being used for IFC 4.3 MVD Based Software Certification.
6 |
--------------------------------------------------------------------------------
/mvdXML1.1/grammar/mvdXMLv1_1.g:
--------------------------------------------------------------------------------
1 | grammar mvdXMLv1_1;
2 |
3 | /*----------------
4 | * PARSER RULES
5 | *----------------*/
6 | expression
7 | : boolean_expression ;
8 | boolean_expression
9 | : boolean_term (logical_interconnection boolean_term)* ;
10 | boolean_term
11 | : (( parameter ( metric )? | metric ) operator ( value | parameter ( metric )? ) ) | ( LPAREN boolean_expression RPAREN );
12 | parameter
13 | : SIMPLEID ;
14 | metric
15 | : '[Value]' | '[Size]' | '[Type]' | '[Unique]';
16 | logical_interconnection
17 | : AND | OR | XOR ;
18 | operator
19 | : EQUAL | NOT_EQUAL | GREATER_THAN | GREATER_THAN_OR_EQUAL | LESS_THAN | LESS_THAN_OR_EQUAL;
20 | value
21 | : logical_literal | real_literal | string_literal | regular_expression;
22 | logical_literal
23 | : FALSE | TRUE | UNKNOWN ;
24 | real_literal
25 | : (sign)? ( DIGIT | INT ) ('.')? ( ( DIGIT | INT ) )? ( 'e' (sign)? ( DIGIT | INT ) )? ;
26 | string_literal
27 | : STRING ;
28 | regular_expression
29 | : 'reg' STRING ;
30 | sign
31 | : '+' | '-' ;
32 |
33 | /*----------------
34 | * LEXER RULES
35 | *----------------*/
36 | AND
37 | : 'AND' | 'and' | '&' | ';' ;
38 | OR
39 | : 'OR' | 'or' | '|' ;
40 | XOR
41 | : 'XOR' | 'xor' ;
42 | EQUAL
43 | : '=' ;
44 | NOT_EQUAL
45 | : '!=' ;
46 | GREATER_THAN
47 | : '>' ;
48 | GREATER_THAN_OR_EQUAL
49 | : '>=' ;
50 | LESS_THAN
51 | : '<' ;
52 | LESS_THAN_OR_EQUAL
53 | : '<=' ;
54 | FALSE
55 | : 'FALSE' | 'false' ;
56 | TRUE
57 | : 'TRUE' | 'true' ;
58 | UNKNOWN
59 | : 'UNKNOWN' | 'unknown' ;
60 | DIGIT
61 | : '0'..'9' ;
62 | INT
63 | : '0'..'9'+;
64 | HEX_DIGIT
65 | : DIGIT | ('a'..'f' | 'A'..'F') ;
66 | LETTER
67 | : ('a'..'z') | ('A'..'Z') ;
68 | SIMPLEID
69 | : LETTER ( LETTER | DIGIT | '_' )* ;
70 | LPAREN
71 | : '(';
72 | RPAREN
73 | : ')';
74 | OCTAL_ESC
75 | : '\\' ('0'..'3') ('0'..'7') ('0'..'7') | '\\' ('0'..'7') ('0'..'7') | '\\' ('0'..'7') ;
76 | UNICODE_ESC
77 | : '\\' 'u' HEX_DIGIT HEX_DIGIT HEX_DIGIT HEX_DIGIT ;
78 | ESC_SEQ
79 | : '\\' ('b'|'t'|'n'|'f'|'r'|'\"'|'\''|'\\') | UNICODE_ESC | OCTAL_ESC ;
80 | STRING
81 | : '\'' ( ESC_SEQ | ~('\\'|'\'') )* '\'';
82 | WS
83 | : (' '|'\t'|'\n'|'\r')+ { $channel = HIDDEN; } ;
84 |
85 |
--------------------------------------------------------------------------------
/mvdXML1.1/mvdXML1-1_WorkingDocument.docx:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/buildingSMART/mvdXML/bd158e10901a2a49c067e3f57449431cab7130f0/mvdXML1.1/mvdXML1-1_WorkingDocument.docx
--------------------------------------------------------------------------------
/mvdXML1.1/xml/Example-CV100.xml:
--------------------------------------------------------------------------------
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
10 |
11 |
12 |
13 |
14 |
15 |
16 | Any product or product type can have associated materials indicating the physical composition of an object.
17 |
18 | Materials can have representations for surface styles indicating colors, textures, and light reflectance for 3D
19 |
20 | rendering. Materials can have representations for fill styles indicating colors, tiles, and hatch patterns for
21 |
22 | 2D rendering. Materials can have properties such as density, elasticity, thermal resistance, and others as
23 |
24 | defined in this specification. Materials can also be classified according to a referenced industry standard.
25 |
26 |
27 |
28 |
29 |
30 | An object can be comprised of a single material or a set of materials with a particular layout. Several
31 |
32 | examples include:
33 |
34 |
35 |
36 |
37 |
38 | - a slab may have an associated layer of concrete;
39 |
40 |
41 |
42 | - a beam may have an associated I-Shape profile of steel;
43 |
44 |
45 |
46 | - a door may have associated constituents for framing and glazing;
47 |
48 |
49 |
50 | - a port may have an associated profile and/or material flowing through it such as hot water.
51 |
52 |
53 |
54 |
55 | ]]>
56 |
57 |
58 |
59 |
60 |
61 |
62 | Material layer set usage defines layout at occurrences to indicate a direction and offset from the 'Axis' reference curve, and a reference extent such as for a default wall height. ]]>
63 |
64 |
65 |
66 |
67 |
68 |
69 |
70 |
71 |
72 |
73 |
74 |
75 |
76 |
77 |
78 |
79 |
80 |
81 |
82 |
83 |
84 |
85 |
86 |
87 |
88 |
89 |
90 |
91 |
92 |
93 |
94 |
95 |
96 |
97 |
98 |
99 |
100 |
101 |
102 |
103 |
104 |
105 |
106 |
107 |
108 |
109 |
110 |
111 |
112 |
113 |
114 |
115 |
116 |
117 |
118 |
119 |
120 |
121 |
122 |
123 |
124 |
125 |
126 |
127 |
128 |
129 |
130 |
131 |
132 |
133 |
134 |
135 |
136 |
137 |
138 |
139 |
140 |
141 |
142 |
143 |
144 |
145 |
146 |
147 |
148 |
149 |
150 |
151 |
152 |
153 |
154 |
155 |
156 |
157 |
158 |
159 |
160 |
161 |
162 |
163 |
164 |
165 |
166 |
167 |
168 |
169 |
170 |
171 |
172 |
173 |
174 |
175 |
176 |
177 |
178 |
179 |
180 |
181 |
182 |
183 |
184 |
185 |
186 |
187 |
188 |
189 |
190 |
--------------------------------------------------------------------------------
/mvdXML1.1/xml/Example-CV104.xml:
--------------------------------------------------------------------------------
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 | Objects may participate in various connectivity
9 | relationships with other objects.
10 |
11 | ]]>
12 |
13 |
14 |
15 |
16 |
17 |
18 | Elements such as doors and windows may be placed inside openings of walls, slabs, or other elements.]]>
19 |
20 |
21 |
22 |
23 |
24 |
25 |
26 |
27 |
28 |
29 |
30 |
31 |
32 |
33 |
34 |
35 |
36 |
37 |
38 |
39 |
40 |
41 |
42 |
43 |
44 |
45 |
46 |
47 |
48 |
49 |
50 |
51 |
52 |
53 |
54 |
55 |
56 |
57 |
58 |
59 |
60 |
61 |
62 |
63 |
64 |
65 |
66 |
67 |
68 |
69 |
70 |
71 |
72 |
73 |
74 |
75 |
76 |
77 |
78 |
79 |
80 |
81 |
82 |
83 |
84 |
85 |
86 |
87 |
88 |
89 |
--------------------------------------------------------------------------------
/mvdXML1.1/xml/Example-CV106.xml:
--------------------------------------------------------------------------------
1 |
2 |
3 |
4 |
5 |
6 |
7 | All files contain a single IfcProject instance indicating overall context and a directory of objects contained within.]]>
8 |
9 |
10 |
11 |
12 |
13 |
14 |
15 |
16 | A project representation context indicates the coordinate system orientation, direction of true north,
17 |
18 | precision, and other values that apply to all geometry within a project or project library.
19 |
20 |
21 | ]]>
22 |
23 |
24 |
25 |
26 |
27 |
28 |
29 |
30 |
31 |
32 |
33 |
34 |
35 |
36 |
37 |
38 |
39 |
40 |
41 |
42 |
43 |
44 |
45 |
46 |
47 |
48 |
49 |
50 |
51 |
52 |
53 |
54 |
55 |
56 |
57 |
58 |
59 |
60 |
61 |
62 |
63 |
64 |
65 |
66 |
67 |
68 |
69 |
70 |
71 |
72 |
73 |
74 |
75 |
76 |
77 |
78 |
79 |
80 |
81 |
82 |
83 |
84 |
85 |
86 |
87 |
88 |
89 |
90 |
91 |
92 |
93 |
94 |
95 |
96 |
97 |
98 |
99 |
100 |
101 |
102 |
103 |
104 |
105 |
106 |
107 |
108 |
109 |
110 |
111 |
--------------------------------------------------------------------------------
/mvdXML1.1/xml/mvdXMLv1-1_example1.xml:
--------------------------------------------------------------------------------
1 |
2 |
3 |
4 |
5 |
7 |
8 |
9 |
10 | Provision of an aggregation structure (or decomposition tree) of physical elments, where the "element" is either the whole or one of the parts of an aggregated structure.
11 | Note: The Aggregation concept is specific to the compositon and decomposition of physical elements. There is no order applied among the parts. Beside the decomposition tree structure, the sub concepts also determine the correct assignment of shape, geometry, property set and other information to either the whole or the parts.
12 | The shape representation of the whole is constructed from the sum of the shape representations of the parts.
]]>
13 |
14 |
16 |
18 |
20 |
21 |
22 |
23 |
25 |
26 |
27 |
28 | Provision of an aggregation structure where the "element", representing the aggregate, is decomposed into parts represented by other elements. The "element" establishes the common object coordinate system to which the parts are placed relative. The "element" shape representation is constructed out of the shape representations of its parts.Note: On import the decomposition structure may not need to be preserved. The parts may either merged into the "element", or may become independent parts. The shape representation and property information however has to be preserved.
]]>
29 |
30 |
31 |
32 |
33 |
35 |
36 |
37 |
38 | Provision of an aggregation structure where the "element" is part of another element representing the aggregate. The "element" then provides the partial shape representation and it is positioned relative to the aggregate.]]>
39 |
40 |
41 |
42 |
43 |
44 |
45 |
47 |
48 |
49 |
50 | Provision of a classification reference as an link to an classification items and corresponding external classification system for the "element". There can be more than one classification reference be provided for the "element".Note: Exchange requirements or local conventions may determine the support of a particular classification system for a certain type of elements.
Note: On import, the classification reference may be shown as a property.
]]>
51 |
52 |
53 |
54 |
55 |
56 |
57 |
58 |
59 |
60 |
61 |
62 |
63 |
64 |
65 |
66 |
67 |
68 |
69 |
70 |
71 |
72 |
73 |
74 |
75 |
76 |
77 |
78 |
79 |
80 |
81 |
82 |
83 |
84 |
85 |
86 |
87 |
88 |
89 |
90 |
91 |
92 |
93 |
94 |
95 |
96 |
97 |
98 |
99 |
100 |
101 |
102 |
103 |
104 |
105 |
106 |
107 |
108 |
109 |
110 |
111 |
112 |
113 |
114 |
115 |
116 |
117 |
118 |
119 |
120 |
121 |
122 |
123 | Specific to IfcBeam: An IfcBeam with a composite profile definition is not handled as decomposition.An example for IfcBeam is an elemented IfcBeam that is decomposed into the IfcBeam section. IfcMember's, IfcFastener's, etc.. These decomposed elements have the geometric 'Body' shape representation, whereas the elemented IfcBeam does not have an own 'Body' shape representation.
]]>
124 |
125 |
126 |
127 |
128 |
129 |
130 |
131 |
132 |
133 |
134 |
135 |
136 |
137 |
138 |
139 | No further restriction of the concept template defined here.
140 | An example for IfcBeam is an IfcElementAssembly such as a frame where the IfcBeam is a part of it. The IfcBeam is then positioned relative to this IfcElementAssembly and represents the shape of that part of the assembly.
]]>
141 |
142 |
143 |
144 |
145 |
146 |
147 |
148 |
149 |
150 |
151 |
152 |
153 |
154 |
155 |
156 |
157 | No further restriction of the concept template defined here.]]>
158 |
159 |
160 |
161 |
162 |
163 |
164 |
165 |
166 |
167 |
168 |
169 |
170 |
171 |
172 |
173 |
174 |
175 |
176 |
177 |
178 |
179 |
180 | No further restriction of the concept template defined here.]]>
181 |
182 |
183 |
184 |
185 |
186 |
187 |
188 |
189 |
190 |
191 |
192 |
193 |
194 | Specific to IfcColumn: An IfcColumn with a composite profile definition is not handled as decomposition.An example for IfcColumn is an elemented IfcColumn that is decomposed into the IfcColumn section. IfcMember's, IfcFastener's, etc. These decomposed elements have the geometric 'Body' shape representation, whereas the elemented IfcColumn does not have an own 'Body' shape representation.
]]>
195 |
196 |
197 |
198 |
199 |
200 |
201 |
202 |
203 |
204 |
205 |
206 |
207 |
208 |
209 | No further restriction of the concept template defined here.
210 | An example for IfcColumn is an IfcElementAssembly such as a frame where the IfcColumn is a part of it. The IfcColumn is then positioned relative to this IfcElementAssembly and represents the shape of that part of the assembly.
]]>
211 |
212 |
213 |
214 |
215 |
216 |
217 |
218 |
219 |
220 |
221 |
222 |
223 |
224 |
225 |
226 |
227 | No further restriction of the concept template defined here.]]>
228 |
229 |
230 |
231 |
232 |
233 |
234 |
235 |
236 |
237 |
238 |
239 |
240 |
241 |
242 |
243 |
--------------------------------------------------------------------------------
/mvdXML1.1/xml/mvdXMLv1-1_example2.xml:
--------------------------------------------------------------------------------
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 | Elements following a path provide an 'Axis' representation indicating a line segment or any arbitrary open bounded curve. Examples of such elements include walls, beams, columns, pipes, ducts, and cables. ]]>
9 |
10 |
11 |
12 |
13 |
14 |
15 |
16 |
17 |
18 |
19 |
20 |
21 |
22 |
23 |
24 |
25 |
26 |
27 |
28 |
29 |
30 |
31 |
32 |
33 |
34 |
35 |
36 |
37 |
38 |
39 |
40 |
41 |
42 |
43 |
44 |
45 |
46 |
47 |
48 |
49 |
50 |
51 |
52 |
53 |
54 |
55 |
56 |
57 |
58 |
59 |
60 |
61 |
62 |
63 |
64 |
65 |
66 |
67 |
68 |
69 |
70 |
71 |
72 |
73 |
74 |
75 |
76 |
--------------------------------------------------------------------------------
/mvdXML1.1/xml/mvdXMLv1-1_example3.xml:
--------------------------------------------------------------------------------
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 | Distribution ports are defined by IfcDistributionPort and attached by the IfcRelNests relationship. Ports are specific to the PredefinedType as follows indicated by the IfcDistributionPort Name, PredefinedType, and FlowDirection:]]>
10 |
11 |
12 |
13 |
14 |
15 |
16 |
17 |
18 |
19 |
20 |
21 |
22 |
23 |
24 |
25 |
26 |
27 |
28 |
29 |
30 |
31 |
32 |
33 |
34 |
35 |
36 |
37 |
38 |
--------------------------------------------------------------------------------
/mvdXML1.1/xml/mvdXMLv1-1_example4.xml:
--------------------------------------------------------------------------------
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
10 |
11 |
12 |
13 |
14 |
15 |
16 |
17 |
18 |
19 |
20 |
21 |
22 |
23 |
24 |
25 |
26 |
27 |
28 |
29 |
30 |
31 |
32 |
33 |
34 |
35 |
36 |
37 |
38 |
39 |
40 |
41 |
42 |
43 |
44 |
45 |
46 |
47 |
48 |
49 |
50 |
51 |
52 |
53 |
54 |
55 |
56 |
57 |
58 |
59 |
60 |
61 |
62 |
63 |
64 |
65 |
66 |
67 |
68 |
--------------------------------------------------------------------------------
/mvdXML1.1/xml/mvdXMLv1-1_example5.xml:
--------------------------------------------------------------------------------
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 | Distribution ports are defined by IfcDistributionPort and attached by the IfcRelNests relationship. Ports are specific to the PredefinedType as follows indicated by the IfcDistributionPort Name, PredefinedType, and FlowDirection:]]>
10 |
11 |
12 |
13 |
14 |
15 |
16 |
17 |
18 |
19 |
20 |
21 |
22 |
23 |
24 |
25 |
26 |
27 |
28 |
29 |
30 |
31 |
32 |
33 |
34 |
35 |
36 |
37 |
38 |
39 |
40 |
41 |
42 |
43 |
44 |
45 |
46 |
47 |
48 |
49 |
50 |
51 |
52 |
53 |
54 |
55 |
56 |
57 |
58 |
59 |
60 |
61 |
62 | A sensor is a device that measures a physical quantity and converts it into a signal which can be read by an observer or by an instrument.]]>
63 |
64 |
65 |
66 |
67 |
68 |
69 |
70 |
71 |
72 |
73 |
74 |
75 |
76 |
77 |
78 |
79 |
--------------------------------------------------------------------------------
/mvdXML1.1/xsd/mvdXML_V1-1_draft.xsd:
--------------------------------------------------------------------------------
1 |
2 |
3 |
4 | Change Log:
5 | 1.1:
6 | schema improvements:
7 | - new complex type GenericReference (used by ModelView and Concept)
8 | - simplified definition of EntityRule and TemplateRule
9 | - definition of applicability attribute changed for ExchangeRequirement and Requirement
10 | - minOccurs changed from 1 to 0 for ModelView.Roots, mvdXML.Templates and Definition.Body
11 | - maxOccurs added to several definitions, mainly for clarification
12 | - definition and use of applicability (was xs:attribute is now xs:simpleType)
13 | - ConceptTemplate.applicableSchema changed to a list of String types
14 | - ConceptRoot.applicableRootEntity now mandatory
15 | schema extensions:
16 | - cardinality attribute of AttributeRule and EntityRule extended to support definition of any min and max settings
17 | - BaseConcept and Override attribute added to Concept
18 | - tags attribute added to Definition
19 | 1.0: first published release
20 | informal restrictions:
21 | - ConceptTemplate.Rules shall be restricted to AttributeRules
22 | - Concept.Rules is limited to TemplateRule and AttributeRule
23 |
24 |
25 |
26 |
27 | The mvdXML element comprises the scope of the mvdXML document, it includes zero-to-many model views and one-to-many concept templates (as a minimum, all concept templates that are referenced on the included model view(s)).
28 |
29 |
30 |
31 |
32 |
33 |
34 |
35 |
36 |
37 |
38 |
39 |
40 |
41 |
42 |
43 |
44 |
45 |
46 |
47 |
48 |
49 |
50 |
51 |
52 |
53 |
54 |
55 |
56 |
57 |
58 |
59 |
60 |
61 |
62 |
63 |
64 |
65 | The ConceptTemplate element represents the reusable concepts, it may have one-to-many sub concept templates and thereby may form a tree of related reusable concepts. Each concept template has an applicable schema and may have applicable root entities (i.e. concept roots to which the concept template applies).
66 |
67 |
68 |
69 |
70 |
71 |
72 |
73 |
74 |
75 |
76 | The ModelView element is the description of a Model View Definition (MVD), it is specific to an IFC schema release and contains one-to-many concept roots. It includes the reference to zero-to-many applicable exchange requirements.
77 |
78 |
79 |
80 |
81 |
82 |
83 |
84 |
85 |
86 |
87 | The Model View Definition (MVD) that represents a subset of the IFC schema to cover the exchange requirements.
88 |
89 |
90 |
91 |
92 |
93 |
94 |
95 |
96 |
97 |
98 |
99 | The ExchangeRequirement element is the description of an Exchange Requirement model (ERM) that is covered by the MVD. An ERM can be referenced from a Concept element to impose specific constraints for exchanges that reference this ERM.
100 |
101 |
102 |
103 |
104 |
105 |
106 |
107 |
108 |
109 |
110 | The ConceptRoot element represents the root element (other terms are "leaf node class", "variable concept") that represent the fundamental parts of an MVD that is represented by a collection of supported concepts. It has an applicable leaf-node IFC entity.
111 |
112 |
113 |
114 |
115 |
116 |
117 |
118 |
119 |
120 |
121 |
122 | The concept template holds the common definitions of a concept, that are independent of its use within a root concept. Concept nodes and concept leaf nodes reference a concept template to share the common description.
123 |
124 |
125 |
126 |
127 |
128 |
129 |
130 |
131 |
132 |
133 |
134 |
135 |
136 |
137 |
138 |
139 |
140 |
141 |
142 |
143 |
144 |
145 |
146 |
147 |
148 |
149 |
150 |
151 |
152 |
153 |
154 |
155 | The root concept (called variable concept in MVD V2.0 documentation). It defines the main and independent entity that is part of a Model View Definition and also provides the root for all path information. Examples are IfcWall, IfcSpace.
156 |
157 |
158 |
159 |
160 |
161 |
162 |
163 |
164 |
165 |
166 |
167 | Each Concept indicates use of a particular template for the applicable root entity.
168 |
169 |
170 |
171 |
172 |
173 |
174 |
175 |
176 |
177 |
178 |
179 | The Concept is an MVD specific concept assigned via a root concept to a model view. It has a reference to a concept template from which it re-uses the definition, it may add a specific definition that only relates to its particular usage for the root element.
180 |
181 |
182 |
183 |
184 |
185 |
186 |
187 |
188 |
189 |
190 |
191 |
192 |
193 |
194 |
195 |
196 |
197 |
198 |
199 |
200 |
201 |
202 |
203 |
204 |
205 |
206 |
207 |
208 |
209 |
210 |
211 |
212 |
213 |
214 |
215 |
216 |
217 |
218 |
219 |
220 |
221 |
222 |
223 |
224 |
225 |
226 |
227 |
228 |
229 |
230 |
231 |
232 |
233 |
234 |
235 |
236 |
237 |
238 |
239 |
240 |
241 |
242 |
243 |
244 |
245 |
246 |
247 |
248 |
249 |
250 |
251 |
252 |
253 |
254 |
255 |
256 |
257 |
258 |
259 |
260 |
261 |
262 |
263 |
264 |
265 |
266 |
267 |
268 |
269 |
270 |
271 |
272 |
273 |
274 |
275 |
276 |
277 |
278 |
279 |
280 |
281 |
282 |
283 |
284 |
285 |
286 |
287 |
288 |
289 |
290 |
291 |
292 |
293 |
294 |
295 |
296 |
297 |
298 |
299 |
300 |
301 |
302 |
303 |
304 | Abstract rule that can either be an attribute rule, an entity rule (both used by ConceptTemplates) or a template rule.
305 |
306 |
307 |
308 |
309 |
310 |
311 |
312 |
313 |
314 |
315 |
316 |
317 | Abstract rule that can either be an attribute rule or an entity rule.
318 |
319 |
320 |
321 |
322 |
323 |
324 |
325 |
326 |
327 |
328 |
329 |
330 |
331 |
332 |
333 |
334 |
335 |
336 |
337 |
338 |
339 |
340 |
341 |
342 |
343 |
344 |
345 |
346 |
347 |
348 |
349 |
350 |
351 |
352 |
353 |
354 |
355 |
356 |
357 |
358 |
359 |
360 |
361 |
362 |
363 |
364 |
365 |
366 |
367 |
368 |
369 |
370 |
371 |
372 |
373 |
374 |
375 |
376 |
377 |
378 |
379 |
380 |
381 |
382 |
383 |
384 |
385 |
386 |
387 |
388 |
389 |
390 |
391 |
392 |
393 |
394 |
395 |
396 |
397 |
398 |
399 |
400 |
401 |
402 |
403 |
404 |
405 |
406 |
407 |
408 |
409 |
410 |
411 |
412 |
413 |
414 |
415 |
416 |
417 |
418 |
419 |
--------------------------------------------------------------------------------
/mvdXML1.2/grammar/ANTLR/mvdXMLv1_2.g:
--------------------------------------------------------------------------------
1 | grammar mvdXMLv1_2;
2 |
3 | /*----------------
4 | * PARSER RULES
5 | *----------------*/
6 | expression
7 | : boolean_expression EOF;
8 | boolean_expression
9 | : boolean_term (logical_interconnection boolean_term)* ;
10 | boolean_term
11 | : NOT? ( ( lhs operator rhs ) | ( LPAREN boolean_expression RPAREN ) );
12 | lhs
13 | : parameter_metric | metric | SELF_TYPE ;
14 | rhs
15 | : parameter_metric | value;
16 | parameter_metric
17 | : parameter (metric)?;
18 | parameter
19 | : simple_id ;
20 | simple_id
21 | : letter ( letter | ZERO | DIGITNONZERO | '_' )* ;
22 | metric
23 | : VALUE | SIZE | TYPE | UNIQUE | EXISTS;
24 | logical_interconnection
25 | : AND | OR | XOR | NAND | NOR | NXOR;
26 | operator
27 | : EQUAL | NOT_EQUAL | GREATER_THAN_OR_EQUAL | GREATER_THAN | LESS_THAN_OR_EQUAL | LESS_THAN;
28 | value
29 | : logical_literal | real_literal | regular_expression | string_literal;
30 | logical_literal
31 | : FALSE | TRUE | UNKNOWN ;
32 | real_literal
33 | : sign? (trailing | int) (DOT decimal_part)? exp? ;
34 | string_literal
35 | : STRING ;
36 | regular_expression
37 | : REG STRING ;
38 | int
39 | : DIGITNONZERO (digit)*;
40 | decimal_part
41 | : trailing? int?;
42 | exp
43 | : EXP sign int;
44 | sign
45 | : PLUS | MINUS ;
46 | digit
47 | : ZERO | DIGITNONZERO;
48 | trailing
49 | : ZERO+;
50 | letter
51 | : EXP | LOWER | UPPER;
52 |
53 | /*----------------
54 | * LEXER RULES
55 | *----------------*/
56 | EQUAL
57 | : '=' ;
58 | NOT_EQUAL
59 | : '!=' ;
60 | GREATER_THAN_OR_EQUAL
61 | : '>=' ;
62 | GREATER_THAN
63 | : '>' ;
64 | LESS_THAN_OR_EQUAL
65 | : '<=' ;
66 | LESS_THAN
67 | : '<' ;
68 | AND
69 | : 'AND' | 'and' | '&' | ';' ;
70 | OR
71 | : 'OR' | 'or' | '|' ;
72 | XOR
73 | : 'XOR' | 'xor' ;
74 | NAND
75 | : 'NAND' | 'nand' ;
76 | NOR
77 | : 'NOR' | 'nor' ;
78 | NXOR
79 | : 'NXOR' | 'nxor' ;
80 | NOT
81 | : 'NOT' | 'not' | '!' ;
82 | VALUE
83 | : '[' ('V'|'v') ('alue'|'ALUE') ']' ;
84 | SIZE
85 | : '[' ('S'|'s') ('ize'|'IZE') ']' ;
86 | TYPE
87 | : '[' ('T'|'t') ('ype'|'YPE') ']' ;
88 | UNIQUE
89 | : '[' ('U'|'u') ('nique'|'NIQUE') ']' ;
90 | EXISTS
91 | : '[' ('E'|'e') ('xists'|'XISTS') ']' ;
92 | FALSE
93 | : 'FALSE' | 'false' ;
94 | TRUE
95 | : 'TRUE' | 'true' ;
96 | UNKNOWN
97 | : 'UNKNOWN' | 'unknown' ;
98 | REG
99 | : 'reg';
100 | SELF_TYPE
101 | : 'SELF_TYPE' | 'self_type' ;
102 | EXP
103 | : 'e' | 'E';
104 | PLUS
105 | : '+';
106 | MINUS
107 | : '-';
108 | DOT
109 | : '.';
110 | LPAREN
111 | : '(';
112 | RPAREN
113 | : ')';
114 | ZERO
115 | : '0';
116 | DIGITNONZERO
117 | : '1'..'9';
118 | LOWER
119 | : 'a'..'z';
120 | UPPER
121 | : 'A'..'Z';
122 | ESC_SEQ
123 | : '\\' ('b'|'t'|'n'|'f'|'r'|'\"'|'\''|'\\') ;
124 | STRING
125 | : '\'' ( ESC_SEQ | ~('\\'|'\'') )* '\'';
126 | WS
127 | : (' '|'\t'|'\n'|'\r')+ -> skip;
128 |
129 |
--------------------------------------------------------------------------------
/mvdXML1.2/grammar/mvdXMLv1_2.g:
--------------------------------------------------------------------------------
1 | grammar mvdXMLv1_2;
2 |
3 | /*----------------
4 | * PARSER RULES
5 | *----------------*/
6 | expression
7 | : boolean_expression ;
8 | boolean_expression
9 | : boolean_term (logical_interconnection boolean_term)* ;
10 | boolean_term
11 | : NOT? ((( parameter ( metric )? | metric ) operator ( value | parameter ( metric )? ) ) | ( LPAREN boolean_expression RPAREN ));
12 | parameter
13 | : SIMPLEID | 'SELF' ;
14 | metric
15 | : '[Value]' | '[Size]' | '[Type]' | '[Unique]' | '[Exists]' ;
16 | logical_interconnection
17 | : AND | OR | XOR | NAND | NOR | NXOR ;
18 | operator
19 | : EQUAL | NOT_EQUAL | GREATER_THAN | GREATER_THAN_OR_EQUAL | LESS_THAN | LESS_THAN_OR_EQUAL;
20 | value
21 | : logical_literal | real_literal | string_literal | regular_expression;
22 | logical_literal
23 | : FALSE | TRUE | UNKNOWN ;
24 | real_literal
25 | : (sign)? ( DIGIT | INT ) ('.')? ( ( DIGIT | INT ) )? ( 'e' (sign)? ( DIGIT | INT ) )? ;
26 | string_literal
27 | : STRING ;
28 | regular_expression
29 | : 'reg' STRING ;
30 | sign
31 | : '+' | '-' ;
32 |
33 | /*----------------
34 | * LEXER RULES
35 | *----------------*/
36 | AND
37 | : 'AND' | 'and' | '&' | ';' ;
38 | OR
39 | : 'OR' | 'or' | '|' ;
40 | XOR
41 | : 'XOR' | 'xor' ;
42 | NAND
43 | : 'NAND' | 'nand' ;
44 | NOR
45 | : 'NOR' | 'nor' ;
46 | NXOR
47 | : 'NXOR' | 'nxor' ;
48 | NOT
49 | : 'NOT' | 'not' | '!';
50 | EQUAL
51 | : '=' ;
52 | NOT_EQUAL
53 | : '!=' ;
54 | GREATER_THAN
55 | : '>' ;
56 | GREATER_THAN_OR_EQUAL
57 | : '>=' ;
58 | LESS_THAN
59 | : '<' ;
60 | LESS_THAN_OR_EQUAL
61 | : '<=' ;
62 | FALSE
63 | : 'FALSE' | 'false' ;
64 | TRUE
65 | : 'TRUE' | 'true' ;
66 | UNKNOWN
67 | : 'UNKNOWN' | 'unknown' ;
68 | DIGIT
69 | : '0'..'9' ;
70 | INT
71 | : '0'..'9'+;
72 | HEX_DIGIT
73 | : DIGIT | ('a'..'f' | 'A'..'F') ;
74 | LETTER
75 | : ('a'..'z') | ('A'..'Z') ;
76 | SIMPLEID
77 | : LETTER ( LETTER | DIGIT | '_' )* ;
78 | LPAREN
79 | : '(';
80 | RPAREN
81 | : ')';
82 | OCTAL_ESC
83 | : '\\' ('0'..'3') ('0'..'7') ('0'..'7') | '\\' ('0'..'7') ('0'..'7') | '\\' ('0'..'7') ;
84 | UNICODE_ESC
85 | : '\\' 'u' HEX_DIGIT HEX_DIGIT HEX_DIGIT HEX_DIGIT ;
86 | ESC_SEQ
87 | : '\\' ('b'|'t'|'n'|'f'|'r'|'\"'|'\''|'\\') | UNICODE_ESC | OCTAL_ESC ;
88 | STRING
89 | : '\'' ( ESC_SEQ | ~('\\'|'\'') )* '\'';
90 | WS
91 | : (' '|'\t'|'\n'|'\r')+ { $channel = HIDDEN; } ;
92 |
93 |
--------------------------------------------------------------------------------
/mvdXML1.2/mvdXML_V1-2-Draft9.pdf:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/buildingSMART/mvdXML/bd158e10901a2a49c067e3f57449431cab7130f0/mvdXML1.2/mvdXML_V1-2-Draft9.pdf
--------------------------------------------------------------------------------
/mvdXML1.2/xsd/mvdXML_V1.2.xsd:
--------------------------------------------------------------------------------
1 |
2 |
3 |
4 |
5 | Change Log:
6 | 1.2 draft:
7 | schema extensions
8 | namespace - updated to: http://buildingsmart-tech.org/mvd/XML/1.2
9 | ModelView.Views - new collection that allows for hierarchical nesting of model views, where the outer view implicitly contains all content of inner views.
10 | TemplateRule.Requirements - new collection for overriding requirements for template, such as for a specific property within a property set.
11 | TemplateRule.References - new collection for representing nested template parameters, such as for properties within a property set.
12 | TemplateRule.Order - new attribute for indicating order of rule for interleaving with rules from other concepts, such as used for properties of different types.
13 | TemplateRule.Usage - new attribute for capturing usage implications, such as for data within a COBie spreadsheet.
14 | 1.1 final-add1:
15 | schema changes
16 | concept.TemplateRules changed from mandatory to optional - It is allowed to have concepts without further configuration via template rules. In that case it is expected that the referenced concept template validates to true.
17 | 1.1 final:
18 | schema extensions
19 | namespace - updated to: http://buildingsmart-tech.org/mvd/XML/1.1
20 | ruleId - new simple type to restrict EntityRule.Reference.@IdPrefix, EntityRule.@RuleId and AttributeRule.@RuleId
21 | EntityRule.Reference.@IdPrefix - changed to ruleID (was normalizedString)
22 | EntityRule.@RuleId - changed to ruleID (was normalizedString)
23 | AttributeRule.@RuleId - changed to ruleID (was normalizedString)
24 | copyright - changed to normalizedString (was anyURI)
25 | 1.1 release candidate
26 | schema extensions
27 | EntityRule.References.Template - new element that allows to reference other templates as partial templates, it allows to reuse common, smaller ConceptTemplate definitions
28 | EntityRule.References.Template.@ref - reference to the partial template by uuid
29 | EntityRule.References.@IdPrefix - an optional prefix for the RuleId name, used to prevent ambiguous RuleId's, if the same partial template is referenced twice in a concept template tree
30 | Concept.TemplateRules - new element and tree structure to define a logical tree (with boolean operators) to combine several template rules
31 | ConceptRoot.Applicability - new element to check, whether the instance of the applicableRootEntity is applicable, allows for more conditions (like certain property values)
32 | @applicableSchema - defined as extensible enumeration of standard IFC schema identifiers.
33 | schema changes - strict version: removed, transitional version: deprecated
34 | AbstractRule - abstract element and conceptType removed, attributes moved to AttributeRule and EntityRule
35 | ConceptTemplate.Rules - restricted to AttributeRule, was an agreement in V1.0, now enforced by schema
36 | AttributeRule.@Cardinality - removed/deprecated: this attribute shall not be used to improse a restriction on the cardinality, restrictions are all handled by template rules
37 | EntityRule.@Cardinality - removed/deprecated: this attribute shall not be used to improse a restriction on the cardinality, restrictions are all handled by template rules
38 | EntityRule.EntityRules - removed/deprecated: There is no usage for an EntityRule to directly contain other EntityRules, without an intermediate AttributeRules
39 | RootConcept.Requirements - removed/deprecated: requirements are only valid for concepts, not for a root concept
40 | Concept.Rules - removed/deprecated: AttributeRules and EntityRules at this level are not legal, replaces by TemplateRules that only allow TemplateRule, and boolean logic
41 | Concept.SubConcepts - removed/deprecated: the inclusion of SubConcepts has no functionality so far, in order to reduce complexity it should not be used, concepts should be flat
42 | Concept.Rules - removed/deprecated: the old Rules structure did not allow for logical combinations of individual rules, it was not defined, what boolean logic should be applied to more than one rule
43 | Cardinality - simple type removed/deprecated, not used any more in AttributeRule or EntityRule
44 | 1.1 draft:
45 | schema improvements:
46 | - new complex type GenericReference (used by ModelView and Concept)
47 | - simplified definition of EntityRule and TemplateRule
48 | - definition of applicability attribute changed for ExchangeRequirement and Requirement
49 | - minOccurs changed from 1 to 0 for ModelView.Roots and mvdXML.Templates
50 | - maxOccurs added to several definitions, mainly for clarification
51 | - definition and use of applicability (was xs:attribute now xs:simpleType)
52 | - ConceptTemplate.applicableSchema changed to a list of String types
53 | schema extensions:
54 | - cardinality attribute of AttributeRule and EntityRule extended to support definition of any min and max settings
55 | - baseConcept and override attribute added to Concept to reference the "supertype" concept
56 | - tags attribute added to Definitions
57 | 1.0: first published release
58 |
59 |
60 |
61 |
62 |
63 |
64 |
65 | The mvdXML element comprises the scope of the mvdXML document, it includes zero-to-many model views and one-to-many concept templates (as a minimum, all concept templates that are referenced in the included model view(s)).
66 |
67 |
68 |
69 |
70 |
71 |
72 |
73 |
74 |
75 |
76 |
77 |
78 |
79 |
80 |
81 |
82 |
83 |
84 |
85 |
86 |
87 |
88 |
89 |
90 |
91 |
92 |
93 |
94 |
95 |
96 |
97 |
98 |
99 |
100 | a list of reusable concept templates, that define the graph within the base IFC schema representing the entities and attributes needed to support the functional unit
101 |
102 |
103 |
104 |
105 |
106 | The ConceptTemplate element represents the reusable concepts, it may have one-to-many sub concept templates and thereby may form a tree of related reusable concepts. Each concept template has an applicable schema and may have applicable root entities (i.e. concept roots to which the concept template applies).
107 |
108 |
109 |
110 |
111 |
112 |
113 |
114 | a list of model view definitions, that contains the necessary entities and associated concepts to define the sub schema of the base schema to support the exchange requirements
115 |
116 |
117 |
118 |
119 |
120 | The ModelView element is the description of a Model View Definition (MVD), it is specific to an IFC schema release and contains one-to-many concept roots. It includes the reference to zero-to-many applicable exchange requirements.
121 |
122 |
123 |
124 |
125 |
126 |
127 |
128 |
129 |
130 |
131 |
132 |
133 |
134 | The concept template holds the common definitions of a concept, that are independent of its use within a root concept. Concept nodes reference a concept template to share the common description. This element represents the reusable concepts; it may have zero-to-many sub concept template's and thereby may form a tree of related reusable concepts. Within the tree it may refer to shared partial concepts. Each concept template has an applicable schema and may have applicable root entities (i.e. concept roots to which the concept template applies).
135 |
136 |
137 |
138 |
139 |
140 |
141 |
142 | Set of attributes defined at applicable Entity, where each attribute may have value constraints and/or graphs of object instances defined. If an attribute is not defined, then the requirements are the same as indicated for the schema.
143 |
144 |
145 |
146 |
147 |
148 | An atribute rule, defined for an attribute of the applicable entity. It declares the root element of the rule tree. It is allowed to define rules for attributes that are defined at subtypes of the applicable entity.
149 |
150 |
151 |
152 |
153 |
154 |
155 |
156 | Set of sub-templates, having a subset of applicable entities, which further define a concept template for particular usage.
157 |
158 |
159 |
160 |
161 |
162 |
163 |
164 |
165 |
166 |
167 |
168 | Identifies the default schema for which the template applies, such as IFC2X_FINAL, IFC2X2_FINAL, IFC2X3, or IFC4. The template may be used for model views of other schemas, if all enclosed rules resolve to available attributes and types.
169 |
170 |
171 |
172 |
173 |
174 |
175 |
176 | Indicates the entities, including all derived entities, for which the concept applies. It is recommended to use a single base class. This value provides the context for any attribute rules and is used within tools to filter the list of available templates for particular entities. For a sub template, the applicable entity must be the same type or a subtype of the outer template. This value may be blank to indicate an abstract template that cannot be instantiated, containing sub templates for specific entities.
177 |
178 |
179 |
180 |
181 |
182 |
183 |
184 |
185 |
186 |
187 |
188 |
189 |
190 |
191 |
192 |
193 |
194 |
195 |
196 |
197 |
198 |
199 |
200 |
201 |
202 |
203 |
204 |
205 |
206 |
207 |
208 |
209 |
210 | Identifies the rule for referencing at template rules defined within concepts, where specific parameters are applied for this rule. NOTE The RuleID must be unique within the scope of its usage.
211 |
212 |
213 |
214 |
215 | Optional description of the rule.
216 |
217 |
218 |
219 |
220 |
221 |
222 |
223 |
224 |
225 |
226 |
227 |
228 |
229 |
230 |
231 |
232 |
233 |
234 |
235 |
236 |
237 |
238 |
239 |
240 |
241 |
242 |
243 |
244 |
245 |
246 |
247 |
248 |
249 |
250 |
251 |
252 | Identifies the rule for referencing at template rules defined within concepts, where specific parameters are applied for this rule. NOTE The RuleID must be unique within the scope of its usage.
253 |
254 |
255 |
256 |
257 | Optional description of the rule.
258 |
259 |
260 |
261 |
262 |
263 |
264 |
265 |
266 | The Model View Definition (MVD) that represents a subset of the IFC schema to cover the exchange requirements. The model view is specific to an IFC schema release and contains zero-to-many c oncept roots. It also includes the reference to zero-to-many applicable exchange requirements. Multiple model views from potentially different releases may be contained in the same file.
267 |
268 |
269 |
270 |
271 |
272 |
273 |
274 | Reference to a base model view definition (in case that this model view represents an add-on model view that extents a base view).
275 |
276 |
277 |
278 |
279 | List of exchange requirements defined within this model view. They should appear in logical order.
280 |
281 |
282 |
283 |
284 |
285 | The ExchangeRequirement element is the description of an Exchange Requirement model (ERM) that is covered by the MVD. An ERM covers the Exchange Requirements (ER) that are identified for a particular exchange scenario that is covered by the MVD. ERM's may add additional constraints to the use of concepts and are an important part of later certification and validation processes. An ERM can be referenced from a Concept element to impose specific constraints for exchanges that reference this ERM.
286 |
287 |
288 |
289 |
290 |
291 |
292 |
293 | Identifies if the ERM is specific for import or export. If such value is provided, then any referencing requirements must match; for example, if such value indicates export, then referencing requirements may use export but not import; if such value is not provided, then referencing requirements may use any value. NOTE The differentiation between import and export origins from software certification and does not have any meaning for data validation applications.
294 |
295 |
296 |
297 |
298 |
299 |
300 |
301 |
302 |
303 |
304 |
305 | List of root concepts defined within scope of the model view.
306 |
307 |
308 |
309 |
310 |
311 | The ConceptRoot element represents the root element (other terms are "leaf node class", "variable concept") that represent the fundamental parts of an MVD that is represented by a collection of supported concepts. It has an applicable leaf-node IFC entity.
312 |
313 |
314 |
315 |
316 |
317 |
318 |
319 | a list of nested model view definitions, that contains the necessary entities and associated concepts to define the sub schema of the base schema to support the exchange requirements
320 |
321 |
322 |
323 |
324 |
325 | The ModelView element is the description of a Model View Definition (MVD), it is specific to an IFC schema release and contains one-to-many concept roots. It includes the reference to zero-to-many applicable exchange requirements.
326 |
327 |
328 |
329 |
330 |
331 |
332 |
333 |
334 |
335 |
336 |
337 | The root concept (called variable concept in MVD V2.0 documentation). It defines the main and independent entity that is part of a Model View Definition and also provides the root for all path information. Examples are IfcWall, IfcSpace.
338 |
339 |
340 |
341 |
342 |
343 |
344 |
345 | A set of TemplateRules, based on a template, which describe the conditions, under which the concepts apply to the applicableRootEntity. Those conditions need to validate to true as a prerequisite for checking the TemplateRules imposed at the concepts.
346 |
347 |
348 |
349 |
350 |
351 |
352 |
353 |
354 |
355 |
356 |
357 | List of concepts defined within scope of the concept root.
358 |
359 |
360 |
361 |
362 |
363 | Each Concept indicates use of a particular template for the applicable root entity.
364 |
365 |
366 |
367 |
368 |
369 |
370 |
371 |
372 |
373 | Identifies the class or data type of instance being described or validated, i.e. the IFC entity (deriving from IfcRoot) for which the concepts apply. The concepts apply to this IFC entity or its subtypes (respectively instances of those classes in case of validation).
374 |
375 |
376 |
377 |
378 |
379 | The Concept is an MVD specific concept assigned via a root concept to a model view. It has a reference to a concept template from which it re-uses the definition, it may add a specific definition that only relates to its particular usage for the root element.
380 |
381 |
382 |
383 |
384 |
385 |
386 |
387 |
388 |
389 |
390 |
391 |
392 |
393 |
394 |
395 |
396 |
397 |
398 |
399 |
400 | List of referenced inner concepts defined within scope of the template rule.
401 |
402 |
403 |
404 |
405 |
406 | Each Concept indicates use of a particular template for the applicable instance referenced at the template rule.
407 |
408 |
409 |
410 |
411 |
412 |
413 |
414 |
415 |
416 |
417 |
418 |
419 |
420 |
421 |
422 |
423 |
424 |
425 |
426 |
427 |
428 | >
429 |
430 |
431 |
432 |
433 |
434 |
435 |
436 |
437 |
438 |
439 |
440 |
441 |
442 |
443 |
444 |
445 |
446 |
447 |
448 |
449 |
450 |
451 |
452 |
453 |
454 |
455 |
456 |
457 |
458 |
459 |
460 |
461 | The element definition contains text and explanatory remarks. It also allows to add links to additional figures, diagrams, examples, and other external documents.
462 |
463 |
464 |
465 |
466 |
467 |
468 | The element holds the definition text or explanatory remarks. It is qualified by a language tag. It also holds tags that further classify the nature of the definition or remark. NOTE In order to correctly encapsulate the HTML formatted text, the content shall be tagged by to preserve the HTML code.
469 |
470 |
471 |
472 |
473 |
474 |
475 | Locale identifier based on RFC 1766 language codes to indicate the default locale. Examples are ‘en’, ‘de’, ‘en-GB’, ’de-CH’.
476 |
477 |
478 |
479 |
480 | List of tags that classify the element. All tags are separated through whitespaces per default. A semicolon must be used if given tags consists of multiple words.
481 |
482 |
483 |
484 |
485 |
486 |
487 |
488 |
489 |
490 |
491 |
492 |
493 |
494 |
495 |
496 |
497 | The element holds all links to additional documentation content, often referenced as a link to external resources.
498 |
499 |
500 |
501 |
502 |
503 | Locale identifier based on RFC 1766 language codes to indicate the default locale. Examples are ‘en’, ‘de’, ‘en-GB’, ’de-CH’.
504 |
505 |
506 |
507 |
508 | Human readable name. This is used as the header of the link content and entry within table of contents when generating documentation.
509 |
510 |
511 |
512 |
513 | Indication about the category of the linked content.
514 |
515 |
516 |
517 |
518 |
519 |
520 |
521 |
522 |
523 |
524 |
525 |
526 |
527 | URL to referenced content, particularly for diagrams and examples that are manually generated. This is used to reference any external files such that they are included when generating documentation. NOTE URL’s local to the file system shall be relative.
528 |
529 |
530 |
531 |
532 |
533 |
534 |
535 |
536 |
537 |
538 |
539 |
540 |
541 |
542 |
543 |
544 |
545 |
546 |
547 |
548 |
549 |
550 |
551 |
552 |
553 |
554 |
555 |
556 |
557 |
558 |
559 |
560 |
561 |
562 |
563 |
564 |
565 |
566 |
567 |
568 |
569 |
570 |
571 |
572 |
573 |
574 |
575 |
576 |
577 |
578 |
579 |
580 |
581 |
582 |
583 |
584 |
585 |
586 | Export means that the software application must be able to create a data set that fulfills defined requirements. If an requirement is defined for import only, it defines the data set that must be properly processed by an application. NOTE The differentiation between import and export origins from software certification and does not have any meaning for data validation applications.
587 |
588 |
589 |
590 |
591 |
592 |
593 |
594 |
595 |
596 |
597 | Definition of the schema name, either predefined representing the official IFC release names IFC2X_FINAL, IFC2X2_FINAL, IFC2X3, and IFC4. Or any other string value.
598 |
599 |
600 |
601 |
602 |
603 |
604 |
605 |
606 |
607 |
608 |
609 |
610 |
611 |
612 |
613 |
614 |
615 |
616 | Universally unique identifier. This is used as a persistent identifier, and must never change. It is string type with a fixed length of 36 characters, which should follow a specific pattern.>
617 |
618 |
619 |
620 |
621 |
622 | Human readable name. This is used as the header of the section and entry within table of contents when generating documentation. The name is also reported for a validation against this mvd, if assigned to concepts checked against the mvd.
623 |
624 |
625 |
626 |
627 | Human readable reference value of this element of the mvd definition.
628 |
629 |
630 |
631 |
632 | Sequential version number of this element of the mvd definition.
633 |
634 |
635 |
636 |
637 | The status information of this element of the mvd definition.
638 |
639 |
640 |
641 |
642 |
643 |
644 |
645 |
646 |
647 |
648 |
649 |
650 |
651 |
652 | The author(s) of this element of the mvd definition. Authors are separated by semicolon.
653 |
654 |
655 |
656 |
657 | The legal owner of this element of the mvd definition NOTE Official Model View Definitions by buildingSMART International shall have ownership assigned to buildingSMART or another accepted standardization organization.
658 |
659 |
660 |
661 |
662 | The copyright under which the work is published. NOTE If adopted by buildingSMART International, the copyright shall lie either with buildingSMART International, or is governed by a well-recognized open license (e.g. creative commons, or open source licences such as BSD or GNU).
663 |
664 |
665 |
666 |
667 |
668 |
--------------------------------------------------------------------------------
/mvdXML1.2/xsd/mvdXML_V1.2_draft3.xsd:
--------------------------------------------------------------------------------
1 |
2 |
3 |
4 |
5 | Change Log:
6 | 1.2 draft 3 (31.01.2020):
7 | schema extensions
8 | Change to unit settings - integrate reference to IFC unit definition (based on ifcXML XSD)
9 | Add new datatype for definition of precisions
10 | schemaName - add regular expression to allow future IFC versions ("IFC[1-9].*")
11 | 1.2 draft 2 (17.01.2020):
12 | schema extensions
13 | DefaultSettings - new element for default precision and unit settings
14 | Constraint.Precision and Constraint.RelativePrecision - new attributes for precision settings added (used by AttributeRule and EntityRule).
15 | TemplateRule.Precision and TemplateRule.RelativePrecision - new attributes for precision settings added (used by Concept)
16 | ConceptRoot.minOccurrence and ConceptRoot.maxOccurrence - new attributes to set constraints on the number of occurrences
17 | ConceptRoot.Specializations and Specialization - new elements that enable to reuse and override definitions
18 | schemaName enumeration list extended to include latest IFC versions (IFC4X1, IFC4X2 and IFC4X3)
19 | TemplateRule.References.IdPrefix - optional attribute added
20 | TemplateRule.RuleMessage - added
21 | 1.2 draft 1:
22 | schema extensions
23 | namespace - updated to: http://buildingsmart-tech.org/mvd/XML/1.2
24 | ModelView.Views - new collection that allows for hierarchical nesting of model views, where the outer view implicitly contains all content of inner views.
25 | TemplateRule.Requirements - new collection for overriding requirements for template, such as for a specific property within a property set.
26 | TemplateRule.References - new collection for representing nested template parameters, such as for properties within a property set.
27 | TemplateRule.Order - new attribute for indicating order of rule for interleaving with rules from other concepts, such as used for properties of different types.
28 | TemplateRule.Usage - new attribute for capturing usage implications, such as for data within a COBie spreadsheet.
29 | 1.1 final-add1:
30 | schema changes
31 | concept.TemplateRules changed from mandatory to optional - It is allowed to have concepts without further configuration via template rules. In that case it is expected that the referenced concept template validates to true.
32 | 1.1 final:
33 | schema extensions
34 | namespace - updated to: http://buildingsmart-tech.org/mvd/XML/1.1
35 | ruleId - new simple type to restrict EntityRule.Reference.@IdPrefix, EntityRule.@RuleId and AttributeRule.@RuleId
36 | EntityRule.Reference.@IdPrefix - changed to ruleID (was normalizedString)
37 | EntityRule.@RuleId - changed to ruleID (was normalizedString)
38 | AttributeRule.@RuleId - changed to ruleID (was normalizedString)
39 | copyright - changed to normalizedString (was anyURI)
40 | 1.1 release candidate
41 | schema extensions
42 | EntityRule.References.Template - new element that allows to reference other templates as partial templates, it allows to reuse common, smaller ConceptTemplate definitions
43 | EntityRule.References.Template.@ref - reference to the partial template by uuid
44 | EntityRule.References.@IdPrefix - an optional prefix for the RuleId name, used to prevent ambiguous RuleId's, if the same partial template is referenced twice in a concept template tree
45 | Concept.TemplateRules - new element and tree structure to define a logical tree (with boolean operators) to combine several template rules
46 | ConceptRoot.Applicability - new element to check, whether the instance of the applicableRootEntity is applicable, allows for more conditions (like certain property values)
47 | @applicableSchema - defined as extensible enumeration of standard IFC schema identifiers.
48 | schema changes - strict version: removed, transitional version: deprecated
49 | AbstractRule - abstract element and conceptType removed, attributes moved to AttributeRule and EntityRule
50 | ConceptTemplate.Rules - restricted to AttributeRule, was an agreement in V1.0, now enforced by schema
51 | AttributeRule.@Cardinality - removed/deprecated: this attribute shall not be used to improse a restriction on the cardinality, restrictions are all handled by template rules
52 | EntityRule.@Cardinality - removed/deprecated: this attribute shall not be used to improse a restriction on the cardinality, restrictions are all handled by template rules
53 | EntityRule.EntityRules - removed/deprecated: There is no usage for an EntityRule to directly contain other EntityRules, without an intermediate AttributeRules
54 | RootConcept.Requirements - removed/deprecated: requirements are only valid for concepts, not for a root concept
55 | Concept.Rules - removed/deprecated: AttributeRules and EntityRules at this level are not legal, replaces by TemplateRules that only allow TemplateRule, and boolean logic
56 | Concept.SubConcepts - removed/deprecated: the inclusion of SubConcepts has no functionality so far, in order to reduce complexity it should not be used, concepts should be flat
57 | Concept.Rules - removed/deprecated: the old Rules structure did not allow for logical combinations of individual rules, it was not defined, what boolean logic should be applied to more than one rule
58 | Cardinality - simple type removed/deprecated, not used any more in AttributeRule or EntityRule
59 | 1.1 draft:
60 | schema improvements:
61 | - new complex type GenericReference (used by ModelView and Concept)
62 | - simplified definition of EntityRule and TemplateRule
63 | - definition of applicability attribute changed for ExchangeRequirement and Requirement
64 | - minOccurs changed from 1 to 0 for ModelView.Roots and mvdXML.Templates
65 | - maxOccurs added to several definitions, mainly for clarification
66 | - definition and use of applicability (was xs:attribute now xs:simpleType)
67 | - ConceptTemplate.applicableSchema changed to a list of String types
68 | schema extensions:
69 | - cardinality attribute of AttributeRule and EntityRule extended to support definition of any min and max settings
70 | - baseConcept and override attribute added to Concept to reference the "supertype" concept
71 | - tags attribute added to Definitions
72 | 1.0: first published release
73 |
74 |
75 |
76 |
77 |
78 |
79 |
80 | The mvdXML element comprises the scope of the mvdXML document, it includes zero-to-many model views and one-to-many concept templates (as a minimum, all concept templates that are referenced in the included model view(s)).
81 |
82 |
83 |
84 |
85 |
86 |
87 |
88 |
89 |
90 |
91 |
92 |
93 |
94 |
95 |
96 |
97 |
98 |
99 |
100 |
101 |
102 |
103 |
104 |
105 |
106 |
107 |
108 |
109 |
110 |
111 |
112 |
113 |
114 |
115 |
116 | Global settings about precision and units that apply to the whole mvdXML file unless overriden by rule specific settings.
117 |
118 |
119 |
120 |
121 |
122 | Global unit settings based on the IFC4 specification for comparison of measurement values. If not defined, comparison of measurement values are based on SI units.
123 |
124 |
125 |
126 |
127 |
128 |
129 |
130 |
131 |
132 |
133 |
134 |
135 |
136 | a list of reusable concept templates, that define the graph within the base IFC schema representing the entities and attributes needed to support the functional unit
137 |
138 |
139 |
140 |
141 |
142 | The ConceptTemplate element represents the reusable concepts, it may have one-to-many sub concept templates and thereby may form a tree of related reusable concepts. Each concept template has an applicable schema and may have applicable root entities (i.e. concept roots to which the concept template applies).
143 |
144 |
145 |
146 |
147 |
148 |
149 |
150 | a list of model view definitions, that contains the necessary entities and associated concepts to define the sub schema of the base schema to support the exchange requirements
151 |
152 |
153 |
154 |
155 |
156 | The ModelView element is the description of a Model View Definition (MVD), it is specific to an IFC schema release and contains one-to-many concept roots. It includes the reference to zero-to-many applicable exchange requirements.
157 |
158 |
159 |
160 |
161 |
162 |
163 |
164 |
165 |
166 |
167 |
168 |
169 |
170 | The concept template holds the common definitions of a concept, that are independent of its use within a root concept. Concept nodes reference a concept template to share the common description. This element represents the reusable concepts; it may have zero-to-many sub concept template's and thereby may form a tree of related reusable concepts. Within the tree it may refer to shared partial concepts. Each concept template has an applicable schema and may have applicable root entities (i.e. concept roots to which the concept template applies).
171 |
172 |
173 |
174 |
175 |
176 |
177 |
178 | Set of attributes defined at applicable Entity, where each attribute may have value constraints and/or graphs of object instances defined. If an attribute is not defined, then the requirements are the same as indicated for the schema.
179 |
180 |
181 |
182 |
183 |
184 | An attribute rule, defined for an attribute of the applicable entity. It declares the root element of the rule tree. It is allowed to define rules for attributes that are defined at subtypes of the applicable entity.
185 |
186 |
187 |
188 |
189 |
190 |
191 |
192 | Set of sub-templates, having a subset of applicable entities, which further define a concept template for particular usage.
193 |
194 |
195 |
196 |
197 |
198 |
199 |
200 |
201 |
202 |
203 |
204 | Identifies the default schema for which the template applies, such as IFC2X_FINAL, IFC2X2_FINAL, IFC2X3, or IFC4. The template may be used for model views of other schemas, if all enclosed rules resolve to available attributes and types.
205 |
206 |
207 |
208 |
209 |
210 |
211 |
212 | Indicates the entities, including all derived entities, for which the concept applies. It is recommended to use a single base class. This value provides the context for any attribute rules and is used within tools to filter the list of available templates for particular entities. For a sub template, the applicable entity must be the same type or a subtype of the outer template. This value may be blank to indicate an abstract template that cannot be instantiated, containing sub templates for specific entities.
213 |
214 |
215 |
216 |
217 |
218 |
219 |
220 |
221 |
222 |
223 |
224 |
225 |
226 |
227 |
228 |
229 |
230 |
231 |
232 |
233 |
234 |
235 |
236 |
237 |
238 |
239 |
240 |
241 |
242 |
243 |
244 |
245 |
246 |
247 |
248 |
249 |
250 | Identifies the rule for referencing at template rules defined within concepts, where specific parameters are applied for this rule. NOTE The RuleID must be unique within the scope of its usage.
251 |
252 |
253 |
254 |
255 | Optional description of the rule.
256 |
257 |
258 |
259 |
260 |
261 |
262 |
263 |
264 |
265 |
266 |
267 |
268 |
269 |
270 |
271 |
272 |
273 |
274 |
275 |
276 |
277 |
278 |
279 |
280 |
281 |
282 |
283 |
284 |
285 |
286 |
287 |
288 |
289 |
290 |
291 |
292 | Identifies the rule for referencing at template rules defined within concepts, where specific parameters are applied for this rule. NOTE The RuleID must be unique within the scope of its usage.
293 |
294 |
295 |
296 |
297 | Optional description of the rule.
298 |
299 |
300 |
301 |
302 |
303 |
304 |
305 |
306 | The Model View Definition (MVD) that represents a subset of the IFC schema to cover the exchange requirements. The model view is specific to an IFC schema release and contains zero-to-many c oncept roots. It also includes the reference to zero-to-many applicable exchange requirements. Multiple model views from potentially different releases may be contained in the same file.
307 |
308 |
309 |
310 |
311 |
312 |
313 |
314 | Reference to a base model view definition (in case that this model view represents an add-on model view that extents a base view).
315 |
316 |
317 |
318 |
319 | List of exchange requirements defined within this model view. They should appear in logical order.
320 |
321 |
322 |
323 |
324 |
325 | The ExchangeRequirement element is the description of an Exchange Requirement model (ERM) that is covered by the MVD. An ERM covers the Exchange Requirements (ER) that are identified for a particular exchange scenario that is covered by the MVD. ERM's may add additional constraints to the use of concepts and are an important part of later certification and validation processes. An ERM can be referenced from a Concept element to impose specific constraints for exchanges that reference this ERM.
326 |
327 |
328 |
329 |
330 |
331 |
332 |
333 | Identifies if the ERM is specific for import or export. If such value is provided, then any referencing requirements must match; for example, if such value indicates export, then referencing requirements may use export but not import; if such value is not provided, then referencing requirements may use any value. NOTE The differentiation between import and export origins from software certification and does not have any meaning for data validation applications.
334 |
335 |
336 |
337 |
338 |
339 |
340 |
341 |
342 |
343 |
344 |
345 | List of root concepts defined within scope of the model view.
346 |
347 |
348 |
349 |
350 |
351 | The ConceptRoot element represents the root element (other terms are "leaf node class", "variable concept") that represent the fundamental parts of an MVD that is represented by a collection of supported concepts. It has an applicable leaf-node IFC entity.
352 |
353 |
354 |
355 |
356 |
357 |
358 |
359 | a list of nested model view definitions, that contains the necessary entities and associated concepts to define the sub schema of the base schema to support the exchange requirements
360 |
361 |
362 |
363 |
364 |
365 | The ModelView element is the description of a Model View Definition (MVD), it is specific to an IFC schema release and contains one-to-many concept roots. It includes the reference to zero-to-many applicable exchange requirements.
366 |
367 |
368 |
369 |
370 |
371 |
372 |
373 |
374 |
375 |
376 |
377 | The root concept (called variable concept in MVD V2.0 documentation). It defines the main and independent entity that is part of a Model View Definition and also provides the root for all path information. Examples are IfcWall, IfcSpace.
378 |
379 |
380 |
381 |
382 |
383 |
384 |
385 | A set of TemplateRules, based on a template, which describe the conditions, under which the concepts apply to the applicableRootEntity. Those conditions need to validate to true as a prerequisite for checking the TemplateRules imposed at the concepts.
386 |
387 |
388 |
389 |
390 |
391 |
392 |
393 |
394 |
395 |
396 |
397 | A set of Specialization settings that enable to apply or override definitions from other ConceptRoots.
398 |
399 |
400 |
401 |
402 |
403 |
404 | A Specialization setting enables either to apply or to override definitions from other ConceptRoots.
405 |
406 |
407 |
408 |
409 |
410 |
411 |
412 |
413 | If override is set to TRUE, then all definitions from referenced ConceptRoots do not apply for objects selected by this ConceptRoot. It enables to override definitions automatically inherited by the IFC inheritance tree. For example definitions for IfcBeam objects can disable definitions inherited from IfcBuildingElement objects. If override is set to FALSE, then all definitions from referenced ConceptRoots should apply for objects selected by this ConceptRoot. It enables to reuse definitions even if referenced applicability does not match.
414 |
415 |
416 |
417 |
418 |
419 |
420 |
421 |
422 |
423 | List of concepts defined within scope of the concept root.
424 |
425 |
426 |
427 |
428 |
429 | Each Concept indicates use of a particular template for the applicable root entity.
430 |
431 |
432 |
433 |
434 |
435 |
436 |
437 |
438 |
439 | Identifies the class or data type of instance being described or validated, i.e. the IFC entity (deriving from IfcRoot) for which the concepts apply. The concepts apply to this IFC entity or its subtypes (respectively instances of those classes in case of validation).
440 |
441 |
442 |
443 |
444 | Minimum number of occurrences that should fulfill the applicability settings. If not given it is allowed to have zero occurrences.
445 |
446 |
447 |
448 |
449 | Maximum number of occurrences that should fulfill the applicability settings. If not given there is not upper limit. If maxOccurrence must be greater than or equal to minOccurrence, if given.
450 |
451 |
452 |
453 |
454 |
455 | The Concept is an MVD specific concept assigned via a root concept to a model view. It has a reference to a concept template from which it re-uses the definition, it may add a specific definition that only relates to its particular usage for the root element.
456 |
457 |
458 |
459 |
460 |
461 |
462 |
463 |
464 |
465 |
466 |
467 |
468 |
469 |
470 |
471 |
472 |
473 |
474 |
475 |
476 |
477 | List of referenced inner concepts defined within scope of the template rule.
478 |
479 |
480 |
481 |
482 |
483 | Each Concept indicates use of a particular template for the applicable instance referenced at the template rule.
484 |
485 |
486 |
487 |
488 |
489 |
490 |
491 |
492 |
493 |
494 |
495 |
496 |
497 |
498 |
499 |
500 |
501 |
502 |
503 |
504 |
505 |
506 |
507 |
508 |
509 |
510 |
511 |
512 |
513 |
514 |
515 |
516 |
517 |
518 |
519 |
520 |
521 |
522 |
523 |
524 |
525 |
526 |
527 |
528 |
529 |
530 |
531 |
532 |
533 |
534 |
535 |
536 |
537 |
538 |
539 |
540 |
541 |
542 |
543 |
544 |
545 |
546 |
547 |
548 |
549 |
550 |
551 |
552 |
553 |
554 |
555 |
556 | The element definition contains text and explanatory remarks. It also allows to add links to additional figures, diagrams, examples, and other external documents.
557 |
558 |
559 |
560 |
561 |
562 |
563 | The element holds the definition text or explanatory remarks. It is qualified by a language tag. It also holds tags that further classify the nature of the definition or remark. NOTE In order to correctly encapsulate the HTML formatted text, the content shall be tagged by to preserve the HTML code.
564 |
565 |
566 |
567 |
568 |
569 |
570 | Locale identifier based on RFC 1766 language codes to indicate the default locale. Examples are ‘en’, ‘de’, ‘en-GB’, ’de-CH’.
571 |
572 |
573 |
574 |
575 | List of tags that classify the element. All tags are separated through whitespaces per default. A semicolon must be used if given tags consists of multiple words.
576 |
577 |
578 |
579 |
580 |
581 |
582 |
583 |
584 |
585 |
586 |
587 |
588 |
589 |
590 |
591 |
592 | The element holds all links to additional documentation content, often referenced as a link to external resources.
593 |
594 |
595 |
596 |
597 |
598 | Locale identifier based on RFC 1766 language codes to indicate the default locale. Examples are ‘en’, ‘de’, ‘en-GB’, ’de-CH’.
599 |
600 |
601 |
602 |
603 | Human readable name. This is used as the header of the link content and entry within table of contents when generating documentation.
604 |
605 |
606 |
607 |
608 | Indication about the category of the linked content.
609 |
610 |
611 |
612 |
613 |
614 |
615 |
616 |
617 |
618 |
619 |
620 |
621 |
622 | URL to referenced content, particularly for diagrams and examples that are manually generated. This is used to reference any external files such that they are included when generating documentation. NOTE URL’s local to the file system shall be relative.
623 |
624 |
625 |
626 |
627 |
628 |
629 |
630 |
631 |
632 |
633 |
634 |
635 |
636 |
637 |
638 |
639 |
640 |
641 |
642 |
643 |
644 |
645 |
646 |
647 |
648 |
649 |
650 |
651 |
652 |
653 |
654 |
655 |
656 |
657 |
658 |
659 |
660 |
661 |
662 |
663 |
664 |
665 |
666 |
667 |
668 |
669 |
670 |
671 |
672 |
673 |
674 |
675 |
676 |
677 |
678 |
679 |
680 |
681 | Export means that the software application must be able to create a data set that fulfills defined requirements. If an requirement is defined for import only, it defines the data set that must be properly processed by an application. NOTE The differentiation between import and export origins from software certification and does not have any meaning for data validation applications.
682 |
683 |
684 |
685 |
686 |
687 |
688 |
689 |
690 |
691 |
692 | Definition of the schema name, either predefined representing the official IFC release names IFC2X_FINAL, IFC2X2_FINAL, IFC2X3, IFC4, IFC4X1, and IFC4X2. Or any other string value.
693 |
694 |
695 |
696 |
697 |
698 |
699 |
700 |
701 |
702 |
703 |
704 |
705 |
706 |
707 |
708 |
709 |
710 |
711 |
712 | Precision setting for comparison of number values. Unless stated to be an absolute precision, the setting is used as relative precision.
713 |
714 |
715 |
716 |
717 |
718 |
719 |
720 |
721 | Enables to switch between absolute (false) and relative precision (true).
722 |
723 |
724 |
725 |
726 |
727 |
728 |
729 |
730 |
731 | Universally unique identifier. This is used as a persistent identifier, and must never change. It is string type with a fixed length of 36 characters, which should follow a specific pattern.>
732 |
733 |
734 |
735 |
736 |
737 | Human readable name. This is used as the header of the section and entry within table of contents when generating documentation. The name is also reported for a validation against this mvd, if assigned to concepts checked against the mvd.
738 |
739 |
740 |
741 |
742 | Human readable reference value of this element of the mvd definition.
743 |
744 |
745 |
746 |
747 | Sequential version number of this element of the mvd definition.
748 |
749 |
750 |
751 |
752 | The status information of this element of the mvd definition.
753 |
754 |
755 |
756 |
757 |
758 |
759 |
760 |
761 |
762 |
763 |
764 |
765 |
766 |
767 | The author(s) of this element of the mvd definition. Authors are separated by semicolon.
768 |
769 |
770 |
771 |
772 | The legal owner of this element of the mvd definition NOTE Official Model View Definitions by buildingSMART International shall have ownership assigned to buildingSMART or another accepted standardization organization.
773 |
774 |
775 |
776 |
777 | The copyright under which the work is published. NOTE If adopted by buildingSMART International, the copyright shall lie either with buildingSMART International, or is governed by a well-recognized open license (e.g. creative commons, or open source licences such as BSD or GNU).
778 |
779 |
780 |
781 |
782 |
--------------------------------------------------------------------------------
/mvdXML1.2/xsd/mvdXML_V1.2_draft8.xsd:
--------------------------------------------------------------------------------
1 |
2 |
3 |
4 |
5 |
6 | Change Log:
7 | 1.2 draft 8 (03.05.2021):
8 | schema extensions
9 | Fix definition for RuleMessages (text element).
10 | 1.2 draft 7 (15.05.2020):
11 | schema extensions
12 | Fix IFC namespace for using unit definitions.
13 | 1.2 draft 6 (29.04.2020):
14 | schema extensions
15 | Use GenericReference in EntityRule
16 | Use new complex type Applicability in ConceptRoot (in addition to TemplateRule and TemplateRules)
17 | 1.2 draft 5 (17.04.2020):
18 | schema extensions
19 | IdPrefix added to GenericReference
20 | Allow multiple references to ConceptTemplates with optional IdPrefix setting
21 | Delete extension proposed in draft 1: TemplateRule.References is replaced by allowing multiple references to ConceptTemplate
22 | Add Applicability (new complext type) to TemplateRules and TemplateRule
23 | 1.2 draft 4 (28.02.2020):
24 | schema extensions
25 | Remove NOT from TemplateRules.operator, add minOccurs of TemplateRule(s) to 2, add negation attribute to TemplateRule
26 | Make TemplateRule.RuleMessage optional (minOccurs = 0)
27 | Add Applicability.RuleMessage
28 | Attribute minOccurrence and maxOccurrence moved to Applicability, change of minOccurs for Template und TemplateRule(s) from 1 to 0
29 | 1.2 draft 3 (31.01.2020):
30 | schema extensions
31 | Change to unit settings - integrate reference to IFC unit definition (based on ifcXML XSD)
32 | Add new datatype for definition of precisions
33 | schemaName - add regular expression to allow future IFC versions ("IFC[1-9].*")
34 | 1.2 draft 2 (17.01.2020):
35 | schema extensions
36 | DefaultSettings - new element for default precision and unit settings
37 | Constraints.Precision and Constraints.RelativePrecision - new attributes for precision settings added (used by AttributeRule and EntityRule).
38 | TemplateRule.Precision and TemplateRule.RelativePrecision - new attributes for precision settings added (used by Concept)
39 | ConceptRoot.minOccurrence and ConceptRoot.maxOccurrence - new attributes to set constraints on the number of occurrences
40 | ConceptRoot.Specializations and Specialization - new elements that enable to reuse and override definitions
41 | schemaName enumeration list extended to include latest IFC versions (IFC4X1, IFC4X2 and IFC4X3)
42 | TemplateRule.References.IdPrefix - optional attribute added
43 | TemplateRule.RuleMessage - added
44 | 1.2 draft 1:
45 | schema extensions
46 | namespace - updated to: http://buildingsmart-tech.org/mvd/XML/1.2
47 | ModelView.Views - new collection that allows for hierarchical nesting of model views, where the outer view implicitly contains all content of inner views.
48 | TemplateRule.Requirements - new collection for overriding requirements for template, such as for a specific property within a property set.
49 | TemplateRule.References - new collection for representing nested template parameters, such as for properties within a property set.
50 | TemplateRule.Order - new attribute for indicating order of rule for interleaving with rules from other concepts, such as used for properties of different types.
51 | TemplateRule.Usage - new attribute for capturing usage implications, such as for data within a COBie spreadsheet.
52 | 1.1 final-add1:
53 | schema changes
54 | concept.TemplateRules changed from mandatory to optional - It is allowed to have concepts without further configuration via template rules. In that case it is expected that the referenced concept template validates to true.
55 | 1.1 final:
56 | schema extensions
57 | namespace - updated to: http://buildingsmart-tech.org/mvd/XML/1.1
58 | ruleId - new simple type to restrict EntityRule.Reference.@IdPrefix, EntityRule.@RuleId and AttributeRule.@RuleId
59 | EntityRule.Reference.@IdPrefix - changed to ruleID (was normalizedString)
60 | EntityRule.@RuleId - changed to ruleID (was normalizedString)
61 | AttributeRule.@RuleId - changed to ruleID (was normalizedString)
62 | copyright - changed to normalizedString (was anyURI)
63 | 1.1 release candidate
64 | schema extensions
65 | EntityRule.References.Template - new element that allows to reference other templates as partial templates, it allows to reuse common, smaller ConceptTemplate definitions
66 | EntityRule.References.Template.@ref - reference to the partial template by uuid
67 | EntityRule.References.@IdPrefix - an optional prefix for the RuleId name, used to prevent ambiguous RuleId's, if the same partial template is referenced twice in a concept template tree
68 | Concept.TemplateRules - new element and tree structure to define a logical tree (with boolean operators) to combine several template rules
69 | ConceptRoot.Applicability - new element to check, whether the instance of the applicableRootEntity is applicable, allows for more conditions (like certain property values)
70 | @applicableSchema - defined as extensible enumeration of standard IFC schema identifiers.
71 | schema changes - strict version: removed, transitional version: deprecated
72 | AbstractRule - abstract element and conceptType removed, attributes moved to AttributeRule and EntityRule
73 | ConceptTemplate.Rules - restricted to AttributeRule, was an agreement in V1.0, now enforced by schema
74 | AttributeRule.@Cardinality - removed/deprecated: this attribute shall not be used to improse a restriction on the cardinality, restrictions are all handled by template rules
75 | EntityRule.@Cardinality - removed/deprecated: this attribute shall not be used to improse a restriction on the cardinality, restrictions are all handled by template rules
76 | EntityRule.EntityRules - removed/deprecated: There is no usage for an EntityRule to directly contain other EntityRules, without an intermediate AttributeRules
77 | RootConcept.Requirements - removed/deprecated: requirements are only valid for concepts, not for a root concept
78 | Concept.Rules - removed/deprecated: AttributeRules and EntityRules at this level are not legal, replaces by TemplateRules that only allow TemplateRule, and boolean logic
79 | Concept.SubConcepts - removed/deprecated: the inclusion of SubConcepts has no functionality so far, in order to reduce complexity it should not be used, concepts should be flat
80 | Concept.Rules - removed/deprecated: the old Rules structure did not allow for logical combinations of individual rules, it was not defined, what boolean logic should be applied to more than one rule
81 | Cardinality - simple type removed/deprecated, not used any more in AttributeRule or EntityRule
82 | 1.1 draft:
83 | schema improvements:
84 | - new complex type GenericReference (used by ModelView and Concept)
85 | - simplified definition of EntityRule and TemplateRule
86 | - definition of applicability attribute changed for ExchangeRequirement and Requirement
87 | - minOccurs changed from 1 to 0 for ModelView.Roots and mvdXML.Templates
88 | - maxOccurs added to several definitions, mainly for clarification
89 | - definition and use of applicability (was xs:attribute now xs:simpleType)
90 | - ConceptTemplate.applicableSchema changed to a list of String types
91 | schema extensions:
92 | - cardinality attribute of AttributeRule and EntityRule extended to support definition of any min and max settings
93 | - baseConcept and override attribute added to Concept to reference the "supertype" concept
94 | - tags attribute added to Definitions
95 | 1.0: first published release
96 |
97 |
98 |
99 |
100 |
101 |
102 |
103 |
104 | The mvdXML element comprises the scope of the mvdXML document, it includes zero-to-many model views and one-to-many concept templates (as a minimum, all concept templates that are referenced in the included model view(s)).
105 |
106 |
107 |
108 |
109 |
110 |
111 |
112 |
113 |
114 |
115 |
116 |
117 |
118 |
119 |
120 |
121 |
122 |
123 |
124 |
125 |
126 |
127 |
128 |
129 |
130 |
131 |
132 |
133 |
134 |
135 |
136 |
137 |
138 |
139 |
140 |
141 |
142 | Global settings about precision and units that apply to the whole mvdXML file unless overriden by rule specific settings.
143 |
144 |
145 |
146 |
147 |
148 |
149 |
150 | Global unit settings based on the IFC4 specification for comparison of measurement values. If not defined, comparison of measurement values are based on SI units.
151 |
152 |
153 |
154 |
155 |
156 |
157 |
158 |
159 |
160 |
161 |
162 |
163 |
164 |
165 |
166 | a list of reusable concept templates, that define the graph within the base IFC schema representing the entities and attributes needed to support the functional unit
167 |
168 |
169 |
170 |
171 |
172 |
173 |
174 | The ConceptTemplate element represents the reusable concepts, it may have one-to-many sub concept templates and thereby may form a tree of related reusable concepts. Each concept template has an applicable schema and may have applicable root entities (i.e. concept roots to which the concept template applies).
175 |
176 |
177 |
178 |
179 |
180 |
181 |
182 |
183 |
184 | a list of model view definitions, that contains the necessary entities and associated concepts to define the sub schema of the base schema to support the exchange requirements
185 |
186 |
187 |
188 |
189 |
190 |
191 |
192 | The ModelView element is the description of a Model View Definition (MVD), it is specific to an IFC schema release and contains one-to-many concept roots. It includes the reference to zero-to-many applicable exchange requirements.
193 |
194 |
195 |
196 |
197 |
198 |
199 |
200 |
201 |
202 |
203 |
204 |
205 |
206 |
207 |
208 | The concept template holds the common definitions of a concept, that are independent of its use within a root concept. Concept nodes reference a concept template to share the common description. This element represents the reusable concepts; it may have zero-to-many sub concept template's and thereby may form a tree of related reusable concepts. Within the tree it may refer to shared partial concepts. Each concept template has an applicable schema and may have applicable root entities (i.e. concept roots to which the concept template applies).
209 |
210 |
211 |
212 |
213 |
214 |
215 |
216 |
217 |
218 | Set of attributes defined at applicable Entity, where each attribute may have value constraints and/or graphs of object instances defined. If an attribute is not defined, then the requirements are the same as indicated for the schema.
219 |
220 |
221 |
222 |
223 |
224 |
225 |
226 | An attribute rule, defined for an attribute of the applicable entity. It declares the root element of the rule tree. It is allowed to define rules for attributes that are defined at subtypes of the applicable entity.
227 |
228 |
229 |
230 |
231 |
232 |
233 |
234 |
235 |
236 | Set of sub-templates, having a subset of applicable entities, which further define a concept template for particular usage.
237 |
238 |
239 |
240 |
241 |
242 |
243 |
244 |
245 |
246 |
247 |
248 |
249 |
250 | Identifies the default schema for which the template applies, such as IFC2X_FINAL, IFC2X2_FINAL, IFC2X3, or IFC4. The template may be used for model views of other schemas, if all enclosed rules resolve to available attributes and types.
251 |
252 |
253 |
254 |
255 |
256 |
257 |
258 |
259 |
260 | Indicates the entities, including all derived entities, for which the concept applies. It is recommended to use a single base class. This value provides the context for any attribute rules and is used within tools to filter the list of available templates for particular entities. For a sub template, the applicable entity must be the same type or a subtype of the outer template. This value may be blank to indicate an abstract template that cannot be instantiated, containing sub templates for specific entities.
261 |
262 |
263 |
264 |
265 |
266 |
267 |
268 |
269 |
270 |
271 |
272 |
273 |
274 |
275 |
276 |
277 |
278 |
279 |
280 |
281 |
282 |
283 |
284 |
285 |
286 |
287 |
288 |
289 |
290 |
291 |
292 |
293 |
294 |
295 |
296 |
297 |
298 |
299 | Identifies the rule for referencing at template rules defined within concepts, where specific parameters are applied for this rule. NOTE The RuleID must be unique within the scope of its usage.
300 |
301 |
302 |
303 |
304 |
305 |
306 | Optional description of the rule.
307 |
308 |
309 |
310 |
311 |
312 |
313 |
314 |
315 |
316 |
317 |
318 |
319 |
320 |
321 |
322 |
323 |
324 |
325 |
326 |
327 |
328 |
329 |
330 |
331 |
332 |
333 |
334 |
335 |
336 |
337 |
338 |
339 | Identifies the rule for referencing at template rules defined within concepts, where specific parameters are applied for this rule. NOTE The RuleID must be unique within the scope of its usage.
340 |
341 |
342 |
343 |
344 |
345 |
346 | Optional description of the rule.
347 |
348 |
349 |
350 |
351 |
352 |
353 |
354 |
355 |
356 |
357 | The Model View Definition (MVD) that represents a subset of the IFC schema to cover the exchange requirements. The model view is specific to an IFC schema release and contains zero-to-many c oncept roots. It also includes the reference to zero-to-many applicable exchange requirements. Multiple model views from potentially different releases may be contained in the same file.
358 |
359 |
360 |
361 |
362 |
363 |
364 |
365 |
366 |
367 | Reference to a base model view definition (in case that this model view represents an add-on model view that extents a base view).
368 |
369 |
370 |
371 |
372 |
373 |
374 | List of exchange requirements defined within this model view. They should appear in logical order.
375 |
376 |
377 |
378 |
379 |
380 |
381 |
382 | The ExchangeRequirement element is the description of an Exchange Requirement model (ERM) that is covered by the MVD. An ERM covers the Exchange Requirements (ER) that are identified for a particular exchange scenario that is covered by the MVD. ERM's may add additional constraints to the use of concepts and are an important part of later certification and validation processes. An ERM can be referenced from a Concept element to impose specific constraints for exchanges that reference this ERM.
383 |
384 |
385 |
386 |
387 |
388 |
389 |
390 |
391 |
392 | Identifies if the ERM is specific for import or export. If such value is provided, then any referencing requirements must match; for example, if such value indicates export, then referencing requirements may use export but not import; if such value is not provided, then referencing requirements may use any value. NOTE The differentiation between import and export origins from software certification and does not have any meaning for data validation applications.
393 |
394 |
395 |
396 |
397 |
398 |
399 |
400 |
401 |
402 |
403 |
404 |
405 | List of root concepts defined within scope of the model view.
406 |
407 |
408 |
409 |
410 |
411 |
412 |
413 | The ConceptRoot element represents the root element (other terms are "leaf node class", "variable concept") that represent the fundamental parts of an MVD that is represented by a collection of supported concepts. It has an applicable leaf-node IFC entity.
414 |
415 |
416 |
417 |
418 |
419 |
420 |
421 |
422 |
423 | a list of nested model view definitions, that contains the necessary entities and associated concepts to define the sub schema of the base schema to support the exchange requirements
424 |
425 |
426 |
427 |
428 |
429 |
430 |
431 | The ModelView element is the description of a Model View Definition (MVD), it is specific to an IFC schema release and contains one-to-many concept roots. It includes the reference to zero-to-many applicable exchange requirements.
432 |
433 |
434 |
435 |
436 |
437 |
438 |
439 |
440 |
441 |
442 |
443 |
444 |
445 | The root concept (called variable concept in MVD V2.0 documentation). It defines the main and independent entity that is part of a Model View Definition and also provides the root for all path information. Examples are IfcWall, IfcSpace.
446 |
447 |
448 |
449 |
450 |
451 |
452 |
453 |
454 |
455 |
456 | A set of Specialization settings that enable to apply or override definitions from other ConceptRoots.
457 |
458 |
459 |
460 |
461 |
462 |
463 |
464 |
465 | A Specialization setting enables either to apply or to override definitions from other ConceptRoots.
466 |
467 |
468 |
469 |
470 |
471 |
472 |
473 |
474 |
475 |
476 | If override is set to TRUE, then all definitions from referenced ConceptRoots do not apply for objects selected by this ConceptRoot. It enables to override definitions automatically inherited by the IFC inheritance tree. For example definitions for IfcBeam objects can disable definitions inherited from IfcBuildingElement objects. If override is set to FALSE, then all definitions from referenced ConceptRoots should apply for objects selected by this ConceptRoot. It enables to reuse definitions even if referenced applicability does not match.
477 |
478 |
479 |
480 |
481 |
482 |
483 |
484 |
485 |
486 |
487 |
488 | List of concepts defined within scope of the concept root.
489 |
490 |
491 |
492 |
493 |
494 |
495 |
496 | Each Concept indicates use of a particular template for the applicable root entity.
497 |
498 |
499 |
500 |
501 |
502 |
503 |
504 |
505 |
506 |
507 |
508 | Identifies the class or data type of instance being described or validated, i.e. the IFC entity (deriving from IfcRoot) for which the concepts apply. The concepts apply to this IFC entity or its subtypes (respectively instances of those classes in case of validation).
509 |
510 |
511 |
512 |
513 |
514 |
515 |
516 | The Concept is an MVD specific concept assigned via a root concept to a model view. It has a reference to a concept template from which it re-uses the definition, it may add a specific definition that only relates to its particular usage for the root element.
517 |
518 |
519 |
520 |
521 |
522 |
523 |
524 |
525 |
526 |
527 |
528 |
529 |
530 |
531 |
532 |
533 |
534 |
535 |
536 |
537 |
538 |
539 |
540 |
541 |
542 |
543 |
544 |
545 |
546 |
547 |
548 |
549 |
550 |
551 |
552 |
553 |
554 |
555 |
556 |
557 |
558 |
559 |
560 |
561 |
562 |
563 |
564 |
565 |
566 |
567 |
568 |
569 |
570 |
571 |
572 |
573 |
574 |
575 |
576 |
577 |
578 |
579 |
580 |
581 |
582 |
583 |
584 |
585 |
586 |
587 |
588 |
589 |
590 |
591 |
592 |
593 |
594 |
595 |
596 |
597 |
598 |
599 |
600 |
601 |
602 |
603 |
604 |
605 |
606 |
607 |
608 |
609 |
610 |
611 |
612 |
613 |
614 |
615 |
616 |
617 |
618 |
619 |
620 |
621 |
622 | The element definition contains text and explanatory remarks. It also allows to add links to additional figures, diagrams, examples, and other external documents.
623 |
624 |
625 |
626 |
627 |
628 |
629 |
630 | The element holds the definition text or explanatory remarks. It is qualified by a language tag. It also holds tags that further classify the nature of the definition or remark. NOTE In order to correctly encapsulate the HTML formatted text, the content shall be tagged by
631 |
632 | to preserve the HTML code.
633 |
634 |
635 |
636 |
637 |
638 |
639 |
640 |
641 | Locale identifier based on RFC 1766 language codes to indicate the default locale. Examples are ‘en’, ‘de’, ‘en-GB’, ’de-CH’.
642 |
643 |
644 |
645 |
646 |
647 |
648 | List of tags that classify the element. All tags are separated through whitespaces per default. A semicolon must be used if given tags consists of multiple words.
649 |
650 |
651 |
652 |
653 |
654 |
655 |
656 |
657 |
658 |
659 |
660 |
661 |
662 |
663 |
664 |
665 |
666 | The element holds all links to additional documentation content, often referenced as a link to external resources.
667 |
668 |
669 |
670 |
671 |
672 |
673 | Locale identifier based on RFC 1766 language codes to indicate the default locale. Examples are ‘en’, ‘de’, ‘en-GB’, ’de-CH’.
674 |
675 |
676 |
677 |
678 |
679 |
680 | Human readable name. This is used as the header of the link content and entry within table of contents when generating documentation.
681 |
682 |
683 |
684 |
685 |
686 |
687 | Indication about the category of the linked content.
688 |
689 |
690 |
691 |
692 |
693 |
694 |
695 |
696 |
697 |
698 |
699 |
700 |
701 |
702 |
703 | URL to referenced content, particularly for diagrams and examples that are manually generated. This is used to reference any external files such that they are included when generating documentation. NOTE URL’s local to the file system shall be relative.
704 |
705 |
706 |
707 |
708 |
709 |
710 |
711 |
712 |
713 |
714 |
715 |
716 |
717 |
718 |
719 |
720 |
721 |
722 |
723 |
724 |
725 |
726 |
727 |
728 |
729 |
730 |
731 |
732 |
733 |
734 |
735 |
736 |
737 |
738 |
739 |
740 |
741 |
742 |
743 |
744 |
745 |
746 |
747 |
748 |
749 |
750 |
751 |
752 |
753 |
754 |
755 |
756 |
757 |
758 |
759 |
760 |
761 | Minimum number of occurrences that should fulfill the applicability settings. If not given it is allowed to have zero occurrences.
762 |
763 |
764 |
765 |
766 |
767 |
768 | Maximum number of occurrences that should fulfill the applicability settings. If not given there is not upper limit. If maxOccurrence must be greater than or equal to minOccurrence, if given.
769 |
770 |
771 |
772 |
773 |
774 |
775 |
776 |
777 |
778 |
779 |
780 |
781 |
782 |
783 |
784 |
785 |
786 |
787 |
788 |
789 |
790 |
791 |
792 | Export means that the software application must be able to create a data set that fulfills defined requirements. If an requirement is defined for import only, it defines the data set that must be properly processed by an application. NOTE The differentiation between import and export origins from software certification and does not have any meaning for data validation applications.
793 |
794 |
795 |
796 |
797 |
798 |
799 |
800 |
801 |
802 |
803 |
804 | Definition of the schema name, either predefined representing the official IFC release names IFC2X_FINAL, IFC2X2_FINAL, IFC2X3, IFC4, IFC4X1, and IFC4X2. Or any other string value.
805 |
806 |
807 |
808 |
809 |
810 |
811 |
812 |
813 |
814 |
815 |
816 |
817 |
818 |
819 |
820 |
821 |
822 |
823 |
824 |
825 |
826 | Precision setting for comparison of number values. Unless stated to be an absolute precision, the setting is used as relative precision.
827 |
828 |
829 |
830 |
831 |
832 |
833 |
834 |
835 |
836 |
837 | Enables to switch between absolute (false) and relative precision (true).
838 |
839 |
840 |
841 |
842 |
843 |
844 |
845 |
846 |
847 |
848 |
849 | Universally unique identifier. This is used as a persistent identifier, and must never change. It is string type with a fixed length of 36 characters, which should follow a specific pattern.>
850 |
851 |
852 |
853 |
854 |
855 |
856 | Human readable name. This is used as the header of the section and entry within table of contents when generating documentation. The name is also reported for a validation against this mvd, if assigned to concepts checked against the mvd.
857 |
858 |
859 |
860 |
861 |
862 |
863 | Human readable reference value of this element of the mvd definition.
864 |
865 |
866 |
867 |
868 |
869 |
870 | Sequential version number of this element of the mvd definition.
871 |
872 |
873 |
874 |
875 |
876 |
877 | The status information of this element of the mvd definition.
878 |
879 |
880 |
881 |
882 |
883 |
884 |
885 |
886 |
887 |
888 |
889 |
890 |
891 |
892 |
893 |
894 | The author(s) of this element of the mvd definition. Authors are separated by semicolon.
895 |
896 |
897 |
898 |
899 |
900 |
901 | The legal owner of this element of the mvd definition NOTE Official Model View Definitions by buildingSMART International shall have ownership assigned to buildingSMART or another accepted standardization organization.
902 |
903 |
904 |
905 |
906 |
907 |
908 | The copyright under which the work is published. NOTE If adopted by buildingSMART International, the copyright shall lie either with buildingSMART International, or is governed by a well-recognized open license (e.g. creative commons, or open source licences such as BSD or GNU).
909 |
910 |
911 |
912 |
913 |
914 |
--------------------------------------------------------------------------------