Proposal: Permit dataType equivalents for non-measure Property values

[andyward]

According to the docs, dataType is a required field when specifying a value.

The implication of this is that the IDS author must know the correct IFC dataType expected for a property. For IfcMeasures this is no doubt important due to Units etc, but for a lot of simple cases this constraint feels overly prescriptive.

For instance an IDS author will now need to specify if a custom property called 'Acme_Reference' has a dataType of IFCTEXT, IFCLABEL, IFCIDENTIFIER or some other datatype. If the IFC exporter doesn't follow these conventions the IDS value check will fail, despite the value matching, and all these IfcTypes being backed by the same EXPRESS STRING type. In any upstream service processing this IFC the property will almost certainly be treated as the same String type so it will feel like a 'false negative' to a typical user.

i.e. To all intents and purposes these are the same to an end user - despite a different semantic:

#10=IFCPROPERTYSINGLEVALUE('Acme_Reference',$,IFCLABEL('Bar'),$);
#11=IFCPROPERTYSINGLEVALUE('Acme_Reference',$,IFCIDENTIFIER('Bar'),$);
#12=IFCPROPERTYSINGLEVALUE('Acme_Reference',$,IFCTEXT('Bar'),$);

I see a couple of options:

1. Make dataType optional again (and update the Audit tool)
2. Allow some limited aliasing between dataTypes at verification

The latter would be my suggestion. My thoughts would be to allow any non-Measure dataType to be deemed equivalent if it's underlying 'Type' is the same. I'd suggest for 99% of cases this is going to types backed by 'string'. You could also make the case that dataTypes such as IfcInteger and IfcPositiveInteger are equivalent but that's perhaps a more subtle edgecase.

Any thoughts?

[Enrra44]

Hi, I think the table should be interpreted differently,	Fields Entered	Required	Optional	Prohibited	Applicability
PSET / NAME	✅	❌	✅	✅
PSET / NAME / [DATATYPE]	✅	✅	❌	✅
PSET / NAME / [DATATYPE] / [VALUE]	✅	✅	❌	✅
PSET / NAME / [VALUE]	❌	❌	❌	❌

The headers are specifying the cardinality (whether your facet PROPERTY is) : 1 - a requirement that is Required 2 - a requirement that is Optional 3 - a requirement that is Prohibited 4 - an Applicability

Edit : only PSET and NAME are mandatory, the other are in brackets to explain what would be acceptable or not when you specify them (https://github.com/buildingSMART/IDS/blob/development/Documentation/specifications.md#cardinality)

In the IDS.XSD schema (1.0.0) it is specified :

<xs:attribute name="dataType" type="ids:upperCaseName" use="optional">
    <xs:annotation>
        <xs:documentation>This is the name of an IFC Defined Type, all uppercase.</xs:documentation>
    </xs:annotation>
</xs:attribute>

The datatype is optional, therefore you can write IDS without it.

Example :

<ids:ids xmlns:ids="http://standards.buildingsmart.org/IDS" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://standards.buildingsmart.org/IDS http://standards.buildingsmart.org/IDS/1.0/ids.xsd">
    <ids:info>
        <ids:title>Test of conformity</ids:title>
        <ids:version>1.0</ids:version>
        <ids:description>test if IDS are passing without the datatype in properties</ids:description>
        <ids:author>author@gmail.com</ids:author>
        <ids:date>2024-07-12</ids:date>
    </ids:info>
    <ids:specifications>
        <ids:specification name="ifcspace are fire escape route" ifcVersion="IFC4X3">
            <ids:applicability>
                <ids:entity>
                    <ids:name>
                        <ids:simpleValue>IfcSpace</ids:simpleValue>
                    </ids:name>
                </ids:entity>
            </ids:applicability>
            <ids:requirements>
                <ids:property>
                    <ids:propertySet>
                        <ids:simpleValue>Pset_SpaceOccupancyRequirements</ids:simpleValue>
                    </ids:propertySet>
                    <ids:baseName>
                        <ids:simpleValue>OccupancyType</ids:simpleValue>
                    </ids:baseName>
                    <ids:value>
                        <ids:simpleValue>9.2</ids:simpleValue>
                    </ids:value>
                </ids:property>
            </ids:requirements>
        </ids:specification>
    </ids:specifications>
</ids:ids>

This will get a pass or fail without specifying the datatype : IDS - Test of conformity.xml.ods EDIT 2 : I agree with you that the table should say that PSET / NAME / [VALUE] is possible in some case (like REQUIRED)

[andyward]

Entirely possible, in which case it's an error in the IDS Audit tool. But I read it as PSET / NAME / [VALUE] is never valid

E.g. then above IDS above gives this error in the audit tool:

info: idsTool.Program[0] Auditing: Ids structure, Ids content.
info: idsTool.Program[0] Auditing file: `C:\Users\AndyWard\source\repos\andyward\IDS-Audit-tool\ids-tool\bin\Debug\net6.0\space.ids`.
info: idsTool.Program[0] The file schema version is: Ids1_0
[**omitted other warnings in this file**]
fail: idsTool.Program[0] Error 203: Incompatible constraints on `property` element at line 19, position 18, specifiying a 'value' requires a 'dataType'.
info: idsTool.Program[0] Completed reading 51 xml elements.
info: idsTool.Program[0] Completed with status: IdsStructureError, IdsContentError.

This 'fail' error disappears if removing the 'value' property.

Looping in @CBenghi in case he can shed some light. Either the docs or the audit tool are incorrect.

I forgot we'd had this discussion before at https://github.com/buildingSMART/IDS/issues/206#issuecomment-1821142540 but I'm unclear on the eventual outcome. Hopefully just a Audit tool issue!

[Enrra44]

Thank you,

Yes I agree with you, your proposition is interesting. And like any case like that, it also raises the question of where is the limit in mandatory and non-mandatory datatype. This will still create a level of precision in the IDS author because they would have to know whether or not the datatype is necessary for such or such property ?

I was using a IFC model in IFC4 and BlenderBIM ADD-on v0.0.240602-47704b1. From my understanding it is still with IDS.XSD 0.9.7 which already had this structure.

This is also a question that I am asking myself, what if an IDS is written with a specification version = 4x3 (in 0.9.7 or IFC4X3_ADD2 in 1.0.0) but the model is not from the same version ? (considering that the applicability and requirements contain only facets with parameters that are included in the IFC4 schema)

[andyward]

This will still create a level of precision in the IDS author because they would have to know whether or not the datatype is necessary for such or such property ?

Hopefully we can get a resolution.

what if an IDS is written with a specification version = 4x3 (in 0.9.7 or IFC4X3_ADD2 in 1.0.0) but the model is not from the same version ? (considering that the applicability and requirements contain only facets with parameters that are included in the IFC4 schema)

Technically the ifcVersion has no actual impact on the test, as per:

specification_version_is_purely_metadata_and_does_not_impact_pass_or_fail_result.ids

However I guess it's up to the validator service to warn if model's schema version is incompatible.