Availability of Applicability testcases

[andyward]

Most of the existing test cases (which are really useful BTW) seem to exercise the Requirements scenarios over the Applicability side of things.

I'm presuming that's since Requirements are the primary focus of the specification, but it would be good to have some reference cases for Applicability so all implementors have the same understanding.

Following on from #177 a few queries I had:

• Presumably any of the 6 facet types can be used for applicability? Each of the markdown docs has a 'Applicability Intention' section that indicates this is the case
• When facets are combined, are we expecting the intersection of the results or the union? (Assumption is it's the Intersection)
• Is sequencing of facets important?
• Can minOccurs/maxOccurs (cardinality) be applied? What does Required, Prohibited and Optional mean in the context of an Applicability facet?
• Can a facet be used more than once? E.g. To find all External elements with a FireRating would be two Property facets.
• What is the expected behaviour with no applicable matches?

Feels like it's worth getting clarity on these if we've not done so already.

[berlotti]

• Presumably any of the 6 facet types can be used for applicability? Each of the markdown docs has a 'Applicability Intention' section that indicates this is the case

yep; as you see in the XSD there is symmetry in applicability and requirements

• When facets are combined, are we expecting the intersection of the results or the union? (Assumption is it's the Intersection)

union. So multiple facets should be interpreted as AND

• Is sequencing of facets important?

not in principle; it is just there to get a valid XSD

• Can minOccurs/maxOccurs (cardinality) be applied? What does Required, Prohibited and Optional mean in the context of an Applicability facet?

there is not required/prohibited/optional anymore in the XSD. This is probably a heritage of a very old experimental version. MinOccurs and MaxOccurs can be used as stated in the XSD. When documentation needs to be updated we would appreciate a hint on where you found this :-)

• Can a facet be used more than once? E.g. To find all External elements with a FireRating would be two Property facets.

not sure if I understand. Yes, you can use multiple facets in a specification. So you can require multiple properties. If you mean reusing a set of requirements to be re-used for multiple specifications that is on the roadmap but not available in the current version.

• What is the expected behaviour with no applicable matches?

depends on the min/max occurs of the specification

[andyward]

Thanks, guess the main point was that it would be handy to codify this in some test cases so we don't get ambiguity.

Just on the point of ambiguity, from my understanding Union = OR, Intersection = AND - just goes to show the imperfections of written requirements ;-)

there is not required/prohibited/optional anymore in the XSD. This is probably a heritage of a very old experimental version. MinOccurs and MaxOccurs can be used as stated in the XSD. When documentation needs to be updated we would appreciate a hint on where you found this :-)

I think we're up to date. I was just using those terms as shorthand as per https://github.com/buildingSMART/IDS/blob/master/Documentation/developer-guide.md#optionality (I've probably mentioned before I think the use of min/maxOccurs is a bit obtuse and an overloading of XSD schema onto the domain, but that's where we are).

For me the core of this 'Optionality' question for me is how does an Applicability facet with maxOccurs=0 behave (or even maxOccurs=*)? Slightly contrived but here's an example. "For all doors without a property linking to the object library we want the CO2e provided":

<specification ifcVersion="IFC2x3" name="Door must have COe2 available ..." description="Any Doors *without* a GS1 GTIN property must have Carbon rating property specified (the others we can easily get COe2 from a product library via GTIN)" minOccurs="0">
	<applicability>
		<entity>
			<name>
				<simpleValue>IFCDOOR</simpleValue>
			</name>
		</entity>
		<property maxOccurs="0">
			<name>
				<simpleValue>GlobalTradeItemNumber</simpleValue>
			</name>
		</property>
	</applicability>
	<requirements>
		<property minOccurs="1" maxOccurs="1">
			<name>
				<simpleValue>Embodied Carbon A1-A3</simpleValue>
			</name>
		</property>
	</requirements>
</specification>

This feels valid, but am not sure if we all have the same understanding over the expected behaviour. Some test cases would be great ;-)

[CBenghi]

From @pasi-paasiala

There's no good test case for classification. For example:

Classification with fixed system name
Classification with regex system name
Classification with fixed value
Classification with regex value

[CBenghi]

Have a test case for Prohibited IfcBuildingElementProxy (through applicability)

[CBenghi]

Applicability also need to be tested with larger models, where filtering is relevant.

[CBenghi]

@atomczak suggested to start from one of the duplex files available here:
https://github.com/buildingSMART/Sample-Test-Files/tree/master/IFC%202x3/Duplex%20Apartment