Multiple ifcVersion about ids HOT 5 CLOSED

My suspicion is that when we keep it like it is, many implementers will add a checkbox:

• Ignore IFC schema version

from ids.

I also think this deserves some thought. I might also be that we're mixing two separate things:

• Compatibility of the IDS with versions of the IFC spec
• Requirement to have a specific version of IFC delivered

For the first we have to keep in mind that with the level of abstraction we're at (e.g material as opposed to IfcMaterialConstituentSet where the last is applicable only to certain schema versions) it should be possible to be fairly agnostic wrt ifc schema version.

For the second if this is the case it maybe should be in the specifications section and should be optional and plural.

from ids.

Good point.
So suggestion is to move 'IfcVersion' to and make it a list.
Makes sense

from ids.

• Compatibility of the IDS with versions of the IFC spec

Totally agree on this, optional is the way to go, also because this would enable to progressively define the content of IDS.
Initially the file might contain facetGroups with a just a name to work out information flows, then their technical implementation might follow, while retaining valid files.

• Requirement to have a specific version of IFC delivered

It would help me in framing this issue to better understand the scope of a single IDS file.
If a single IDS were to cover multiple deliverables at some project stage (i.e. models provided by Arch, Stuct, MEP...) we would certainly need to expand to a list.

But I would prefer a scenario where an IDS is negotiated by provider/consumers on a more atomic level, and in that case a clear constraint to a version would make life easier for any code that goes and gets the data out of it.

Similarly to the issue I raised on the widespread use of idsValue (#39), I think that being more heavy handed on requirements would result in better workflows enabled by IDS.

from ids.

updated in 0.5.6

from ids.