This is an ambiguity in the documentation which we need to resolve.
The docs explicitly state that root level tasks must be declared to the project. Here is the evidence:
5.3.3.10 IfcWorkPlan
If an assigned IfcTask is a root-level task, such task must be declared on the IfcProject using the IfcRelDeclares relationship.
In addition, the docs also suggest that controls are optional. Here is the evidence:
5.3.3.6 IfcTask
Occurrences of IfcTask may be assigned to an IfcWorkControl
Therefore, at face value, you are absolutely correct that linking tasks to controls is optional.
However, the IFC docs need a bit of scrutiny, for example:
-
Why is this evidence for declaring root level tasks only mentioned on the IfcWorkPlan page, and not the IfcTask, IfcProcess, IfcRelAssignsToControl, IfcRelDeclares, or any other page?
-
IFC docs are written from the perspective of "finished" data, not WIP data where you first create tasks and then later organise them. So if having root tasks declared to a project is "finished" data, what does it actually mean for a user semantically? Does it have meaning?
-
Pre-IFC4, all tasks had to be declared to the project, but in IFC4, the declaration is indirect via a control. Is this evidence stale? Is it perhaps old documentation that needs to be removed?
-
Why are there no diagrams / figures showing this scenario?
For the moment, the IfcOpenShell API follows the docs as strictly as possible and does not prevent you from doing exactly what you're looking for - rooted tasks declared to projects with no controls, and later assigning controls. However, in the BlenderBIM Add-on UI, we have created a GUI that doesn't allow the user to do this - for the simple reason that we don't know what it means in practice, or how it benefits the user.
To resolve this, either:
-
Find a usecase for what you're mentioning that can be proposed to buildingSMART and documented more explicitly than the little hints that we are going off right now, and then we can re-jig the BlenderBIM Add-on UI to support it.
-
Discover that there is no strong usecase for what you're asking, and therefore remove all hints that suggest it exists.
From experience in implementing other portions of the spec where the spec seems to hint at flexibility, I've almost always discovered that this is not true - there is actually a "correct" way of doing it (as you'd expect from an ISO standard), just that the IFC wording needs to be improved to reduce ambiguity.