Documentation of implicit agreements

[MatthiasWeise]

Seeing the example IDS_aachen_example.xml it seems that there is a keyword "attribute" for checking an attribute instead of property (I would normally expect that "attribute" should be the name of IfcPropertySet.Name).

Is there a documentation about such implicit agreements or keywords?

Extract from mentioned example:

<ids:requirements>
	<ids:property location="instance">
		<ids:propertyset>
			<ids:simpleValue>attribute</ids:simpleValue>
		</ids:propertyset>
		<ids:name>
			<ids:simpleValue>name</ids:simpleValue>
		</ids:name>
		<ids:value>
			<xs:restriction>
					<xs:pattern value="^(Wanddurchbruch.*|Deckendurchbruch.*)" />
			</xs:restriction>
		</ids:value>
	</ids:property>
</ids:requirements>

[berlotti]

Using 'attribute' as the propertySet name is the only convention, hence the example.
Use-cases have shown users want to define IFC attributes as requirements. These do not have a property set name.

There are already discussion to use instead of this convention, but since attributes most probably disappear in IFC 5, the IDS XSD can stay the same for use in different IFC versions.

This topic is on the list for phase 2.

[MatthiasWeise]

I guess the propertySet statement includes checking of Quantities as well (they are quite similar to Pset). Anyhow, such agreements need to be documented in the IDS spec. Otherwise there will be too much room for interpretation.

[aothms]

Indeed, what has been on the table potentially is some sort of reference implementation using a language with well defined semantics (like schematron or sparql) that can act as a formal definition of the spec and as a neutral referee when there are discrepancies in vendor implementations.

[MatthiasWeise]

Yes, having a formal represenation of a checking rule makes sense and is most likely needed to avoid misinterpretation. I was wondering if the ConceptTemplates and used RuleIDs published with the IFC specification could be used as a reference (at least to identify the relevant parts of IFC).

[aothms]

Yes they would be great entry points into the documentation. Whether they can be directly reused probably depends on e.g the choices re properties and quantities and how they are handled specifically. I think a conversion to mvdXML also makes sense at some point, but for a semantic basis I'm not sure how complete it is wrt e.g universal and existential qualification, which might be needed.

[berlotti]

attributes now split into separate node/element