How to deal with xs:restriction base attribute in relation with IfcMeasure value

[berlotti]

IfcMeasure element is now added to properties (please review).
There are a couple of comments and open questions:

• ifcMeasure needs to 'fit' with the IFC Property of the schema (in case of using IFC properties and Psets)
• how to deal with the value of ifcMeasure, and the xs:restriction base?

For example IfcAreaMeasure is defined as being given in square meters (m2) in the IDS (defined on https://github.com/buildingSMART/IDS/wiki/Physical-Quantities-and-Units).
For the value in the property value element it means restrictions need to be in m2. For example a pipe needs to have a value between 2 and 6 square meters.
This means the restrictions need to be addressed as:

<xs:restriction base="xs:integer">
<xs:minInclusive value="2"/>
<xs:maxInclusive value="6"/>
</xs:restriction>

The minInclusive and MaxInclusive are defined by the 'base' attribute in the xs:restriction element. In this example set as 'integer'.
What is the implication of the value of this 'base' element for using fixed physical quantities and units?

[aothms]

This is an important topic. Equality of floating point numbers should generally always be considering a tolerance value, due to rounding errors and all. For that same reason inclusive and exclusive generally don't make a big difference when comparing floating point numbers.

• We can decide on a global|local and fixed|user-defined relative|absolute tolerance. I would be inclined to say something like the following (global, fixed, relative): for determining equality of floating point numbers value_ifc and value_ids we do not do value_ifc == value_ids but rather value_ids * (1. - 1e-6) < value_ifc < value_ids * (1. + 1e-6) . This would cover mostly the rounding issues when using 32bit floating point math (7 signficant digits). For that reason I'd say it also doesn't need to be configurable, it's only specifically for rounding errors, not for let's say construction-related tolerances in which case users need to supply an explicit range. But it's a topic with a lot of diverging ideas, this is just a quick suggestion.
• For the ranges we can either decide that the inclusive|exclusive part is ignored on floats, that we only allow one of the two for floats, or that inclusive|exclusive somehow affects the tolerance.
• Should we also make some statement on supporting xsd:float xsd:double xsd:decimal?

I don't expect huge demand for constrained floats, so I think we should be pragmatic about it, but also explicit.

[pasi-paasiala]

I think the restriction base shouldn't be integer, since the properties are almost always floating point numbers. The values in the restriction should always be given in the same based unit that is given for the measure. So if there's a requirement, that a temperature should be between 20 to 25 degrees Celsius. The limits in IDS should be 293.15 and 298.15, since temperature is given in Kelvin.

[berlotti]

This is now solved with the settlement of the measures