Allow numeric and boolean simpleValue (#342)

[BIMvoice]

Addresses #342.

The problem, reproduced

Schema/ids.xsd line 41 declares:

<xs:element name="simpleValue" type="xs:string" minOccurs="1" maxOccurs="1"/>

so xmlschema.encode() rejects a raw Python 2.0 with 2.0 is not an instance of <class 'str'>, exactly as @atomczak reported. Confirmed against the current schema.

Two things worth stating up front about scope:

• No already serialized .ids file is affected. XML element text is textual regardless of declared type, so this is purely encode side ergonomics for type strict data binders. Validating existing files is unchanged.
• Documentation/UserManual/restrictions.md already says "A Simple Value may be text, a number, or a boolean (TRUE / FALSE)", and tolerance.md refers to "doubles in ids:simpleValue", so numeric and boolean content is already documented as normal usage. Only the XSD type is narrower than the documentation.

The change

<xs:element name="simpleValue" minOccurs="1" maxOccurs="1">
    <xs:simpleType>
        <xs:union memberTypes="xs:string xs:decimal xs:integer xs:boolean"/>
    </xs:simpleType>
</xs:element>

Two refinements on the proposal in the issue: xs:integer rather than xs:int, matching the base types already used throughout DataTypes.md, and xs:boolean added, which answers @janbrouwer's question in the thread, since a Python True hits the identical encode error.

Member order matters, and this is the part worth reviewing

xs:string must stay first. With numeric types first, decode() starts returning Decimal and bool objects instead of str for numeric looking text, silently changing the contract for every existing consumer that expects simpleValue to decode as a string. I confirmed this with a deliberately reordered control. With xs:string first, encode accepts native numeric and boolean values while decode is provably unchanged.

Validation

• Red: the reproduction script fails against the current schema with the reporter's exact error. Green: it passes against this one.
• All 330 .ids files under Documentation/ were validated against the current schema and this one: zero differences in validity verdict.
• IfcOpenShell's IfcTester test suite with this schema swapped in: 37/37, identical to baseline.

Note that IfcTester itself was never affected, since it casts any value to str before encoding. The defect only reaches third party tools that build IDS XML directly against ids.xsd.

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