Facets review

[CBenghi]

Working progress revision of the schema and documentation.

[pjanck]

I haven't looked through the documentation changes, since the text seems very WIP today.

[CBenghi]

I haven't looked through the documentation changes, since the text seems very WIP today.

Indeed that is more of a set of working notes that will need to be distributed in the rest of the documentation.
PRs are welcome for that.

[andyward]

The rationale for this change to the way entity facet's PredefinedType behaviour makes total sense. However it may be worth considering the implications for implementors (both during spec creation and model validation). Particularly for 'early-bound' IFC implementations I can see challenges when traversing from an Element (generally of a known type) to any defining ElementType's PredefinedType enum attribute. The issue being you don't know what Type you'll get at runtime, which provides the enum Type.

Take as an example: an IDS specifier can presumably define an entity facet as:
Name: IFCFLOWTERMINAL
SubType: BATH (the enum from IfcSanitaryTerminalTypeEnum)

(Obviously in IFC4 onward you might be able to use Name = IfcSanitaryTerminal, but not in 2x3)

So two issues:

1. The design interface (and IDS validator) would need to prompt/allow all appropriate enum values for a FlowTerminal - from all potential DefiningTypes
2. In order to query that PredefinedType value on the ElementType at runtime you've some casting and coercion to do, and a runtime performance hit.

All doable, but it would be a lot more efficient and easier to implement if there were some means to specify the Type as part of the entity. It would also be more expressive: you could select all sanitary equipment in IFC2x3.

I guess the question is: are we considering these kinds of complex uses of PredefinedType/SubType for IDS 1.0? Entity Facets seem most often used on applicability rather than requirements so it's important these kinds of query predicates can be employed consistently across implementations or we'll be testing different sets of applicable items.

[NickNisbet]

I need to require that an IfcElement MUST have an IfcElementType. * Is requiring an attribute ‘PredefinedType’ with pattern restriction ‘.*’ the way to do this? (preferred) * Is requiring an entity ‘subType’ with pattern restriction ‘.*’ the way to do this? Regards

[andyward]

I need to require that an IfcElement MUST have an IfcElementType.

• Is requiring an attribute ‘PredefinedType’ with pattern restriction '.*' the way to do this? (preferred)
• Is requiring an entity ‘subType’ with pattern restriction ‘.*’ the way to do this?

Regards, Nick.

Nick, I'm not sure either would work reliably - any validator would presumably only flag up issues where there was a PredefinedType attribute value on the ElementType but not on the Element. So as a requirement it might work for my IfcFlowTerminal=>IsTypedBy=>IfcSanitaryTerminalType example above (any value must come from the Type). And it would work for say IfcBeam and IfcBeamType in IFC2x3 but not in later schemas since IfcBeam.PredefinedType got introduced in Ifc4. And wouldn't work in any schema for IfcPile since PredefinedType existed on both Element and Type since IFC2x3.

Probably needs a separate issue if there's not one already...

Andy

[MatthiasWeise]

I need to require that an IfcElement MUST have an IfcElementType.

• Is requiring an attribute ‘PredefinedType’ with pattern restriction '.*' the way to do this? (preferred)
• Is requiring an entity ‘subType’ with pattern restriction ‘.*’ the way to do this?

Regards, Nick.

Nick, I'm not sure either would work reliably - any validator would presumably only flag up issues where there was a PredefinedType attribute value on the ElementType but not on the Element. So as a requirement it might work for my IfcFlowTerminal=>IsTypedBy=>IfcSanitaryTerminalType example above (any value must come from the Type). And it would work for say IfcBeam and IfcBeamType in IFC2x3 but not in later schemas since IfcBeam.PredefinedType got introduced in Ifc4. And wouldn't work in any schema for IfcPile since PredefinedType existed on both Element and Type since IFC2x3.

Probably needs a separate issue if there's not one already...

Andy

May check this issue (related to IFC2x3 types): #116

[gverduci]

Hi Claudio,
the extension of the attributeType contains the attribute group "xs:occurs" and the new attribute cardinality (line 156).
Maybe it is a mistake

[gverduci]

The entity name in the restriction test case "fail-an_enumeration_matches_case_sensitively_1_3.ids" is in pascal case format

<applicability minOccurs="0" maxOccurs="unbounded">
  <entity>
    <name>
      <simpleValue>IfcWall</simpleValue>
    </name>
 </entity>
</applicability>

[gverduci]

Classification test cases:

• pass-occurrences_override_the_type_classification_per_system_1_3.ids
• pass-occurrences_override_the_type_classification_per_system_3_3.ids

The related ifc files contain two IfcWalls but only one classified: the ids files fail due to the presence of an unclassified wall

[CBenghi]

Hi Claudio, the extension of the attributeType contains the attribute group "xs:occurs" and the new attribute cardinality (line 156). Maybe it is a mistake

Hi @gverduci, thanks. I think I spotted that too while revising the schema. It should be solved now.

[gverduci]

Hi Claudio,
the file "classification/fail-an_optional_classification_value_fails_if_no_match.ids" contains a title and a specification name with a different meaning than the file name.

This file contains an optional requirement with system and value, and the related ifc file contains an IFCWALL without classifications.

For the optional case with system and value, the facet-configuration.md file says:
"OPTIONAL
SYSTEM/VALUE:
entity -> if there is a classification system for the entity to be tested, its value must match"

Is it correct that this test fails?

[gverduci]

the file "material/fail-an_optional_material_fails_if_no_value_matches.ids" contains a title and a specification name with a different meaning than the file name

[CBenghi]

Hi @gverduci,

with regards to your comments:

classification/fail-an_optional_classification_value_fails_if_no_match.ids
Is it correct that this test fails?

I think the origina IFC had a problem, it attached the classification to the project rather than the wall, it should now be ok.
It should fail, because the classification is an empty string and should not match the expected value.

the file "material/fail-an_optional_material_fails_if_no_value_matches.ids" contains a title and a specification name with a different meaning than the file name

I've changed the code so that we are notified of the title mismatches on testcase regeneration, see 9d37660.

Thanks for spotting these.

[andyward]

Hi @CBenghi, when regenerating the testcases (which I assume closes out #192 ?) were you able to fix the invalid IFC for pass-occurrences_override_the_type_classification_per_system_1_3.ids

There's a whole bunch of open issues for this one bad test as every implementor seems to hit it: e.g. #108, #194, #225

There's a dead simple fix: change the type of one of the entities so it doesn't get affected by prior test data.

#226 (comment)

[vi55i]

I have never understood what minOccurs and maxOccurs mean in an applicability statement.

[MatthiasWeise]

There was a long debate about the meaning of min/maxOccurs settings in specification. The decision from an engineering point of view was to ask for a specific number of instances that can be selected by applicability where ALL instances must fulfill specified requirements. This is the reason to move from specification to applicability, because this cardinality restriction is purely for number of instances that fulfill the applicability statement.

In contrast to that, we did not see a use case asking for a specific number of instances that are selected by applicability AND fulfill specified requirements.

Anyhow, most generic EIRs will use min=0 and max=unbounded, meaning that ALL instances fulfilling the applicability settings should fulfill our requirements. There are only few examples where other settings make sense and most of them seem to be addressed either in the IFC schema (1 instance of IfcProject) or implementer agreements (1 instance of IfcSite/IfcBuilding). Other examples like "I need 10 office rooms in my building" are more project specific.

[andyward]

I'd expect minOccurs=1 to be common too? i.e. "There must be at least one space in my building [and they should all satify requirement ...]"

[MatthiasWeise]

I agree that minOccurs=1 can be a useful requirement. It basically defines that some types of objects are expected to be in the model. So, it is an easy way to check if something is missing. However, it comes with the limitation that you do not check that all rooms are really modelled by an IfcSpace object.

Instead of doing such limited minOccurs=1 checks I would prefer something like checking through relationships, e.g. inner walls must be a boundary of 2 spaces, outer walls must be a boundary of 1 space, etc.

[MatthiasWeise]

Looks good and seems to be the complete list!
If we want to focus on measurements that should be converted, I think we can reduce the list (essentially all measurements without a link to SI units).

No need for conversion or unclear conversion process:

• IFCCONTEXTDEPENDENTMEASURE
• IFCCOUNTMEASURE
• IFCDESCRIPTIVEMEASURE
• IFCNUMERICMEASURE
• IFCPHMEASURE

Other questionable measurements are:

• IFCNORMALISEDRATIOMEASURE
• IFCPOSITIVERATIOMEASURE
• IFCRATIOMEASURE
• IFCMONETARYMEASURE (no fixed conversion rate)

[CBenghi]

I agree, I've forgot that I left the full list.
I'll improve the file document.

[CBenghi]

Done.
Why do you think there's unclear conversion for ph?
I don't think it's going to need any conversion, and be in the range {0.0 <= SELF <= 14.0}
But there are other such cases in the documentation for completeness.

I think we will have to add a testcases suite for the entire set of measures.

[MatthiasWeise]

Why do you think there's unclear conversion for ph? I don't think it's going to need any conversion, and be in the range {0.0 <= SELF <= 14.0} But there are other such cases in the documentation for completeness.

I think we will have to add a testcases suite for the entire set of measures.

That was my point, everything what does not need a conversion does not have to be included in the list. If always between 0 and 14, we can remove it.

[MatthiasWeise]

I was wondering if we should differentiate between three categories:

1. values that may need a conversion before comparison (everything that is defined by SI-units)
2. values that do not need a conversion as there is only one way to represent the data (ph, count, numeric and ratio)
3. values that shall not be used for comparison as there is no standardised way for representing them (monetary, context dependent, descriptive)

To be safe, we can exclude category 3 from value checks (except for existance/not existance).

[CBenghi]

Hi @andyward,
I think I fixed the issue with that IFC file, but I was not following the relevant issues, so I hope I did it right.
I have not implemented the updated verification logic for a while, so your help is much welcome if you have a list of open testcase issues.
Also, now that IDS generation is automated I would like to do the same for IFC, your advice much welcome there too, if you have any.
I'm thinking to produce a number of IFC files that can match the requirements (e.g. combinatorial variation of relevant schemas and element solutions). Think only of the many options that we have when it comes to materials!

[andyward]

Hi @andyward,
I think I fixed the issue with that IFC file, but I was not following the relevant issues, so I hope I did it right.
I have not implemented the updated verification logic for a while, so your help is much welcome if you have a list of open testcase issues.
Also, now that IDS generation is automated I would like to do the same for IFC, your advice much welcome there too, if you have any.
I'm thinking to produce a number of IFC files that can match the requirements (e.g. combinatorial variation of relevant schemas and element solutions). Think only of the many options that we have when it comes to materials!

Sure, I'll see if we can integrate the tests from this PR. Last I checked we pass all the current testcases except 1-2 or esoteric edge cases (ie6 tolerance and Predefined Properties are the only 2 I'm aware of) - so suggest we get it all (regression) tested on 0.9.7, and then can look at additional tests. Is there an XIDS update with the latest IDS schema?

Should be able to help with the IFC generation. That said I think Dion's testcases cover most of the material cases already. Multi-schema would be good to test. I also think Applicability needs some test cases (Currently the tests focus on Requirement). There's a whole bunch of scenarios with restrictions on applicability where it would be good to have a standard set of test cases for.