Document why compound measures are absent from DataTypes (#297)

[BIMvoice]

Addresses #297.

The omission is correct, and worth saying so

@MatthiasWeise asked whether IfcCompoundPlaneAngleMeasure's absence from the datatype table is intentional. It is, and for a structural reason that is easy to re-derive but currently written down nowhere, so the next reader will ask the same question.

Verified against the schema in IFC2X3, IFC4 and IFC4X3_ADD2:

IfcCompoundPlaneAngleMeasure   list [3:4] of integer
IfcComplexNumber               array [1:2] of real
IfcPlaneAngleMeasure           real                    (present in the table)

The table's stated job is to give each usable data type its xs:base type for xs:restriction purposes. An aggregate has no single scalar value to restrict, so no base type applies.

This is a consistent rule rather than an oversight. Enumerating every aggregate-declared type across all three schema versions gives IfcComplexNumber, IfcCompoundPlaneAngleMeasure, IfcArcIndex, IfcLineIndex and IfcPropertySetDefinitionSet, and all five are absent, in every version, without exception. The only scalar measure missing is none: everything else absent with "Measure" in its name is an abstract SELECT type rather than a usable data type.

On @aothms's point

He noted that even where the value cannot be constrained, it should still be possible to require the data type. That already works. Measured against IfcOpenShell's IfcTester with an IfcWall carrying Pset_Alignment.Bearing = IfcCompoundPlaneAngleMeasure(12,34,56):

dataType="IFCCOMPOUNDPLANEANGLEMEASURE"        PASS
dataType="IFCLABEL"                            FAIL, "does not match the required data type"
plus a simpleValue restriction on top          FAIL, does not silently pass

So the capability exists and discriminates correctly. The note records that too, since it is the practical answer to the original question.

Scope

Prose only, no table rows changed. The table is generated from the audit tool repository, but the surrounding prose is hand maintained in the same file, following the existing IFCSTRIPPEDOPTIONAL note directly above this insertion.

@CBenghi noted in the thread that the audit tool and documentation would both be updated; this covers the documentation half only.

This PR was created with the assistance of an AI coding tool.