Do you say Bill East projects “DON’T NEED” PDTs?
So if needs, means still those projects are dependent on PDT and IfcProduct which are under the construction 
And those .html files were good for 10 years ago, not today, and Bill East like others (including me) have to wait to see what would be final PDT and IfcProduct and develop those .html pages based on them
Even I say PDT is NOT good enough
@jwouellette Which concequenses of a growing schema do you think will be a problem? (so that we can narrow the discussion a bit…?)
Will it become a performance issue? I guess not. We could probably add 1000 more classes to IFC without a big performance hit, but that may vary between implementations. There should be room to add many more new domains to the schema at least.
Will it require changes in the implementations and thus be a burden for the implementers? I don’t think so. An IFC viewer only needs to implement some concepts:
And if the viewer also want to be able to display properties and information about any object, it will also be interested in:
And there are probably some more that I’ve forgotten.
Other concepts are more optional. For example, for some, it could be nice if the viewer knew about systems and ports.
But even if you add many more domains, this list is probably not going to change/grow much for viewers. There will probably not be invented (many) new concepts that will be mandatory for all viewers to understand. Which means that you can add many new domains to the schema without splitting into modules, and existing viewers will still work. And existing architecture applications will still be able to view the objects from additional domains that it doesn’t know about etc.
I think introducing modules may be much more of a hazzle and require more implementation work than not introducing them. But again, I have soo little information to go on here. You have said so little about the motivation for this and the ideas so far.
Okay, I can work with that. The issue I have with this is that in IFC Bridge we proposed a few MVDs that allowed the implementers to decide what they want to support. The Bridge Reference View did not feature linear referencing (IfcAlignment etc.) just bridge specific building elements such as IfcBearing or IfcCaissonFoundation whereas the Bridge Alignment based RV did. So modularization can be achieved with MVD. The funny thing with this is that implementing a new IfcBuildingElement subtype is easy. As @Helland has wonderfully explained in one of his posts. Practically everything is inherited from IfcBuildingElement, all that is new are the Predefined Types.
Is this really the biggest problem we are currently facing? How about IfcDoc development? Me and @jonm are implementing requirements from Rail and Infra projects but there is no real strategy. How about addressing some of the issues of the .mvdxml schema that @Helland and many other projects are facing? You yourself have opened a few of the issues also being discussed on these forum in your next post. (want to take you up on opening a new topic)
This is a bit harsh. Both me @Helland, @DrShawnOKeeffe have wondered about the objective of this proposal/discussion. It is not being dismissive but can we really be constructive if we do not know the objective and the consequences?
The main issue is “relationships” and how to mage them, they always have caused issues
I think IFD/IFC needs a good modeling language which it seems that UML/SysML can solve this issue and bSI is thinking about it
Then your insights totally would be right
This is what I’m thinking and have been explaining (probably not as good as I could have), unless there are bigger issue to bring to the surface!
Perhaps in a new topic…but, I’m curious why IfcDoc versus ISO ISO /IEC 19757-3:2016 Schematron? Other professionals in this area have stated that Schematron is the better direction, for more reasons than simply the lack of IfcDoc development.
What is the problems with the relationships?
They are by the way one of the most modularized things we have in the schema. It is easy for new domains to add new relations to existing classes without requiring any change on the existing classes. They can just add a new relation class.
The problem with relationships that I’ve already mentioned, is that you cannot have a relationship to an object from another file. (which is the same as you probably are talking about, when you say we need federated files)
Schematron is not a new topic, we purposed it (but today I think even Schematron is not a good choice, some month ago I was saying it is)
The main issue is IFD/IFC is totally dependent to IfcDoc and this is NOT good
So ask yourself why today we have a lot of poor implementations?
Indeed, “the consequences”. Risk must be weighed. In general, it sounds like based on this Modularisation proposal, everything to date will be affected, and in many case things go back to day 1 of the IAI. I would really like the MVD consequences clarified. @berlotti…feel free to chime in!
I don’t know what you are hinting about. I’m an implementer of one specific implementation. I don’t have user experience from other IFC implementations. So you have to tell me about these problems.
So, let’s categorize all obstacles we think cause poor implementation in the industry and then answer them one by one
I think IFC provides a relationship strategy which wants brings flexibility, but this flexibility in other side causes some poor implementation, maybe some implementers don’t have enough knowledge, I don’t know
No. Please provide real examples. Don’t categorize abstract, subjective and undocumented ideas.
Modularisation already exists, and it called Model View Definitions. It seem Modularisation is being used as an enabler to allow poor software engineering without proper systems analysis and poor contractual behavior. This so-called Modularisation would prevent proper standard information exchanges to flourish globally. It’s known folks are creating their own information exchanges in parts of Europe due to software inability and forcing them in and out of software not built to handle the rubbish, and this Modularisation is catering to this improper behavior.
Modularisation as presented and discussed herein will prevent proper testing of information against contractual agreements as MVDs are meant to satisfy. If this Modularisation comes into existence we will not be able to share contracted information deliverables in a standard way because people globally will be doing what they feel like doing versus following standard information exchanges that can be contractually agreed and objectively tested in the same manner no matter the location globally. we fight this now with folks forcing information into coordination models versus agreeing on standard MVDs we can all utilize.
Millions of US taxpayer dollars went into creating a foundation to battle this problem, by the USACE ERDC conducting the Life Cycles information exchange Project, resulting in several standard contractable MVDs of which bSI to date has ignored. It hurts to see such waste and a proposal that would only add fuel to the fire that folks worked so hard and put so much time and money into to put out those flames. It’s really sad to see the new proposed direction that has become clear over these pass days. I hope the focus goes back on contractable information exchanges that can be objectively tested, where if the data has not met the standard then folks will simply not get paid.
Too much nonsense is going on in the Construction sector with information modeling and data wrangling where no one actually knows if the job has been done correctly. In the days where we drew by hand, one could not put crap all over my drawings and demand to be paid. however, now this is the case with “BIM”. We have an opportunity to do this properly, so let’s not create a mechanism where we allow garbage in and out of software and pat each other on the back and say well done!
Until we have MVDs that are testable against contracted information exchanges, we shall continue to suffer in industry as a whole. Modularisation will not solve this. In fact, we already have Modularisation, called an MVD.
I don’t follow you here. What is “this modularization” you are talking about? I’ve not yet seen any actual examples of what this modularization is going to be, so it is way too early to say that it can’t be objectively tested for example.
I agree that modularization sounds like something that should be solved by MVD. But people should still be allowed to discuss other ideas as well. And maybe the outcome of the dicussion is some features that are currently missing in MVD, so maybe modularization really is MVD 2.0 or something.
The problem with this discussion is still that noone knows what this modularization is and why it is wanted/needed. And that why part has to be properly established first. We cannot discuss or invent modularization if there is no commonly understood reasons for its existence.
Still waiting on @jwouellette and @berlotti to further explain the problems that needs to be solved by modularization.
Thanks @Helland. That is indeed the major lesson from this: the cause/motive needs clarification. Working on that right now!
If that’s the only part you do not follow, then I’m sure we are on the same page! 
Answer:
One in which MVD as we know it is abolished?
Waiting to see if that’s part of the “motive” and an effect of the “cause”.
Thanks Leon!
I think the only way we can show together what we have in mind is to work on different ideas and let the industry choose which solutions are better
And I think the majority have started this approach
My approach as I said before is to add IDM/MVD Configurator inside the software and let software users the ability to do anything “inside the software”
From IFD, IFC and IDM and MVD setting, to UC, to ER, to MVD, to anything, the whole workflow would be flexible and under the “users” control
Yes, definitely new topic. But just to shortly reply. I look at IfcDoc through the lens of documentation generation and schema editing more than just validation. But sure, Schematron is definitely worth considering as an addition for schema validation. Maybe adding it to every publication in computer interpretable listings.
Coming in late, I saw good ideas, e.g. from @nn1, @DrShawnOKeeffe, @sergej and @Helland. On the other hand the topic is complex and multifaceted, therefore there is a danger to mix up the different topics, like modularization vs. mvd vs. certification vs. base modelling languages (UML, SysML, etc.). Here is my view:
Modularization: (of a schema) - to me it means mainly that I cluster the overall IFC schema into certain parts in order to manage it (rather) independently from other parts (by different persons, etc.). To some degree that was always the case in IFC development (see the architecture diagram, born back in late 1990’ies). But when it came to package all for implementation in software, all was combined into a single, first EXPRESS, later also XSD schema file.
Model view definitions: from a software perspective - obviously no software can support data against the complete schema. In order to avoid that the sender and the receiver uses / expects data written against different parts of the schema, there was the need to limit the scope of the schema (creating a subschema) that more comprehensively describe the common subset of the expected exchange. This is what an MVD is - a subset of the total IFC schema, plus additional constraints imposed on that subset, that restricts the scope of the data exchange for a set of exchange scenarios (e.g. all exchanges, that rely of linking of discipline models - ako Reference View).
Exchange requirements: from a user perspective, the IDM method was born (early 2000) in order to describe the data exchange needs between different processes or disciplines in terms of expected data deliveries. Later something similar came up as part of the LOD (D for definition, not detail) discussions - the LOI (level of information) - [side note: to me, someone should at one time define the commonalities and differences between these two IDM and LOIN (which is the new term in ISO 19650) - right now it is a big confusion]. Unfortunately the terms “Model View Definition” and “Exchange Requirements” are continuously mixed up confusing all.
E.g. there are 100++ different exchange requirements dealing with different attributes assigned to model elements - whereas in IFC this is one concept called “property set”. So in principle, it requires only one MVD (containing property sets) to satisfy 100++ exchange requirements.
mvdXML - the specification was created for three (separate) reasons:
Modularization and MVD is not the same, MVD and Exchange requirments are not the same, and by chosing UML as the main language to define the schema (and some tool to actually handling the UML diagrams, like enterprise architect) those questions are not answered either.
Still I see the need to move away from ISO/EXPRESS to more mainstream language/tool such as UML. And the need to use standard tools for modeling. This is aroute to go (and yes, as @jwouellette said, there a many discussion, whether to use straight UMLor sysML - e.g. the STEP community decided to move to sysML).
I am not so sure about Modularization versus MVD - going by (large) packages to subdivide the total IFC schema and use those as subsets for implementation/certification lacks in my view the fexibility of the MVD approach (in particular the use of concept templates). And as @nn1 said, there is hardly any domain specific class. For me, it should not be differentiated by domain, but rather by: