https://standards.buildingsmart.org/documents/Implementation/IFC_Implementation_Agreements/
Is it safe to say that every CV is either directly implemented in IFC4+ or it is implied that CV holds true for every IFC schema version? Should CV’s be updates for newer schemas?
This has been proposed 3 months ago, but either no action has been taken, or that action is behind closed doors: https://github.com/buildingSMART/NextGen-IFC/issues/42
I find it odd that buildingSMART decides to lock these issues instead of letting the community continue to address them. There is no avenue to follow-up on these requests, @TLiebich mentioned a Git repository, but none has been communicated in this forum (or did I miss it?)
With no communication, I share @claimred’s concern that the implementer agreements need revisiting, and either merging into the IFC4 documentation, or obsoleting.
There was an attempt several years ago to go through every single IFC2x3 CV and decide if it was still relevant or not. The general consensus was that IFC4 should generally have no CVs, and that everything should be included as part of the base documentation. I don’t know where that suggestion stands re: the current documentation.
@angel.velez I’ve heard that too as that was the theory. In practice, however, some CVs are still used to resolve ambiguous behaviour (e.g. the whole material / surface colour issue)
Exactly, yeah. Colors issue is definitely a hot topic.
A couple of CVs we were wondering about are about Doors and Windows.
CV-2x3-181 in particular is confusing imho. Parametric doors/windows representation (i.e. ParameterTakesPrecedence = TRUE attribute value) is still in IFC4+ schemas without deprecated flags. Yet, it’s mentioned in the CV that it should always be false, explicit geometry should be provided and not rely on LiningProperties.
First, it’s just a bit weird not to be able to have parametric doors representation in IFC, isn’t it? Especially considering DTV is on it’s way.
Second, there is a special check report example about certain door/window objects where there is implied that https://b-cert.org/Documentation/CheckReportExample.
Am I missing something?
Just to clarify my understanding of the terminology: “CV” stands for “Coordination view” which is an IFC2x3 MVD, “CV” does not mean “Implementer’s agreement”. The naming of the agreements is based on the fact that implementer’s agreements used to be valid only in the context of an MVD and specific information exchange case. That is why they did not live in the main specification. Can someone confirm this?
@tauscher You are correct. Every IA identifies how it is applied, usually to a specific MVD.
@claimred and @moult The truth is, both the IFC2x3 certification and IFC4 developments were happening in parallel, with some IAs not occurring until well after things had been locked down in the IFC4 development. Yes, there are some things that would be best “locked down” or simplified in the IFC4 schema from the lessons learned and agreed in IFC2x3 execution, but in an imperfect reality, not everything was resolved. Everyone recognizes this and we are trying to make sure we don’t make the same mistakes for IFC5.
@jwouellette cheers - so to prevent the same mistakes in IFC5 - what is the avenue to resolve these IAs one by one? The Github issue I linked to has been locked, so I’m not sure where to further the discussion, and if any progress has been made.
Every IA identifies how it is applied, usually to a specific MVD.
@jwouellette @tauscher Thanks for the answers! I think I got a bit confused because IFC4 IAs are still named CV-4-* though while there is no Coordination View for IFC4+ schemas.
Could you please clarify my question about parametric Doors & Windows? Should IFC4 RV MVD support parametric Doors & Windows or should they have explicit shape representation and ParameterTakesPrecedence be deprecated?
The second option seems closer in spirit to RV I guess.
Another IA I was wondering about is this: CV-2x3-178
In this cases with
IfcRelConnectsElementsit is possible to represent this relation without losing information. TheIfcRelConnectsElements.RelatingElementthen points to the building element, such asIfcWall, whereas theIfcRelConnectsElements.RelatedElementpoints to theIfcOpeningElementIfcDoor/IfcWindow.
It should be modified like this. Am I correct?
I agree with you that it seems not appropriate to use or allow this option in the RV MVD. This is, however, not the same as deprecation. A deprecated element is marked for complete removal from the specification. The annotation “deprecated” is used for a transition period where implementers should still be able to consume files with this type or attribute, but they are encouraged not to produce any more instances, because in future standards versions the element will be removed. I think this not the case here. Other MVDs might still allow the element, just RV would probably not.
I think we’ll just have to make sure that this is another issue that gets picked up as we review the progress of the IFC5 Task Force. Maybe @berlotti and @TLiebich have another idea to track this.
I agree with you that it seems not appropriate to use or allow this option in the RV MVD. This is, however, not the same as deprecation. A deprecated element is marked for complete removal from the specification.
Thanks! Do you think I should create a github issue-proposal for that change in Reference View?
Speaking of moving forward, I think it would be neat to mention current IAs about colors in the colors discussion happening right now. 
https://standards.buildingsmart.org/documents/Implementation/IFC_Implementation_Agreements/
It seems like IA’s page, as well as @TLiebich guide, is no longer accessible from the main page https://technical.buildingsmart.org/. Is that intentional?
hmm, I just checked it, the page is accessible for me and I can download all linked material (pdf, etc.). Maybe a temporary issue?
@berlotti did some extensive reorganization of the entire technical website. I’ll ping him again on this.
The page was under revision. It has been updated and is now back in the menu as well.
