In xmlschema 4.0 it started to throw a more generic XMLSchemaValidationError - I guess there are many things that can trigger validation check and in the new version some other issue gets there first.
I don't like this, but PyPI makes it really, really hard to "discover"
optional deps and what they're used for. So it's just easier to make it
a mandatory dependency and advanced users can always strip it out. This
stops user reports about "it doesn't work out of the box I only did pip
install ifctester"
The IDS documentation used to state that "optional" on requirement
facets was "for information only" and didn't affect the pass / fail
state. This was changed a while ago (which I missed) to a new behaviour:
both no values and passing values will pass.
Previously Bonsai would show a wall of errors, now it's show a simple error message and redirecting to system console for the details.
Example error - https://i.imgur.com/uJJfjUW.png
Example validation error details in console - https://i.imgur.com/3mcVBUh.png
Same details but in text:
Validation error details:
failed validating {'dataType': 'IFCBOOLEAN', 'ursi': 'https://google.com', 'cardinality': 'required', 'instructions': "Make sure it's true"} with XsdAttributeGroup(['dataType', 'uri', 'cardinality', 'instructions']):
Reason: 'ursi' attribute not allowed for element
Schema component:
<xs:extension xmlns:xs="http://www.w3.org/2001/XMLSchema" base="ids:propertyType">
<xs:attribute name="uri" type="xs:anyURI" use="optional" />
<xs:attribute name="cardinality" type="ids:conditionalCardinality" use="optional" default="required" />
<xs:attribute name="instructions" type="xs:string" use="optional">
<xs:annotation>
<xs:documentation>Author of the IDS can leave instructions for the authors of the IFC. This text could/should be displayed in the BIM/IFC authoring tool.</xs:documentation>
</xs:annotation>
</xs:attribute>
</xs:extension>
Instance type: <class 'xml.etree.ElementTree.Element'>
Instance:
<ids:property xmlns:ids="http://standards.buildingsmart.org/IDS" dataType="IFCBOOLEAN" ursi="https://google.com" cardinality="required" instructions="Make sure it's true">
<ids:propertySet>
<ids:simpleValue>Pset_WallCommon</ids:simpleValue>
</ids:propertySet>
<ids:baseName>
<ids:simpleValue>Combustible</ids:simpleValue>
</ids:baseName>
<ids:value>
<ids:simpleValue>false</ids:simpleValue>
</ids:value>
</ids:property>
Path: /ids:ids/ids:specifications/ids:specification/ids:requirements/ids:property[1]
Previously for both cardinality optional/required ifctester would show same results.
E.g.
<ids:property dataType="IFCBOOLEAN" cardinality="required">
<ids:property dataType="IFCBOOLEAN" cardinality="optional">
Were resulting in something like
LoadBearing data shall be true and in the dataset Pset_WallCommon
LoadBearing data shall be true and in the dataset Pset_WallCommon
Now it will result in
LoadBearing data shall be true and in the dataset Pset_WallCommon
LoadBearing data may be true and in the dataset Pset_WallCommon
The input value can be a string or number, but 1.0 schema only accepts strings. The processing of int and float was missing. The casting to string might no longer be needed in IDS 1.1. https://github.com/buildingSMART/IDS/issues/342
Dion Moult
