Proposal: Permit dataType equivalents for non-measure Property values
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 30/100
Research direction
Start with Documentation/facet-configurations.md and Documentation/DataTypes.md, then read the unresolved alternatives and comment history. Determine and document the agreed rule for equivalent non-Measure dataTypes, including whether the Audit tool is affected. Done means the rule, related documentation, and verification behavior have an explicit, tested outcome.
Written by the indexing model from the issue text.
Description
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:
- Make dataType optional again (and update the Audit tool)
- 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?
- Dominant language
- C#
- Stars
- 319
- Forks
- 90
- PR merge metrics
- No merged PRs in 30d
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from buildingSMART/IDS
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
buildingSMART/IDS#422 · 2 comments ·
-
please contribute tests
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
buildingSMART/IDS#354 · 3 comments ·
-
Difficulty 5/5 Over a week Newbie friendliness 42/100
buildingSMART/IDS#448 · 5 comments · 1 reaction ·
-
audit tool discuss & decide documentation
Difficulty 4/5 3-5 days Newbie friendliness 38/100
buildingSMART/IDS#446 · 1 reaction ·
-
agreed please contribute tests
buildingSMART/IDS#435 · 2 comments · 1 assignee ·
All issues in buildingSMART/IDS
Similar issues
-
bug
Difficulty 1/5 Under an hour Newbie friendliness 90/100
-
Type: enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
apache/arrow-adbc#4809 ·
-
type/automation type/tech-debt
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
microsoft/vscode-azurefunctions#5197 · 1 comment ·
-
Difficulty 1/5 Under an hour Newbie friendliness 85/100
microsoft/microsoft-ui-reactor#1274 ·