buildingSMART / buildingSMART/IDS

Symmetry is broken between applicability and requirements due to nullness

Open
#430 4 comments 0 reactions 0 assignees View on GitHub
discuss & decide
Dominant language
C#
Stars
318
Forks
90
PR merge metrics
No merged PRs in 30d

Description

It used to be that a facet was symmetrical. For example, a facet applied to an entity would result in either True or False. If you used that facet as an applicability True = applicable, False = not applicable. As a requirement, True = pass, False = fail.

I've noticed that the documentation has now changed such that this symmetry is broken. A facet used as an applicability seems to be always be treated as the "required" situation, whereas a facet used as a requirement has different meanings.

For example:
- Applicability (required): Property(pset=Pset_Foo, basename=Foobar) - Matches if Pset_Foo.Foobar is filled in
- Requirement (required): Property(pset=Pset_Foo, basename=Foobar) - Matches if Pset_Foo.Foobar exists, even if null

Another example:
- Applicability (prohibited): Property(pset=Pset_Foo, basename=Foobar) - Matches if Pset_Foo.Foobar is filled in
- Requirement (prohibited): Property(pset=Pset_Foo, basename=Foobar) - Matches if Pset_Foo.Foobar exists, even if null

Is this intentional? It acts as an edge case for users which can lead to surprise, and also means code is less straightforward to implement.

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.