search

buildingSMART / NextGen-IFC

61 stars 4 forks source link

Is it possible to get IFC standards development to be quicker and more agile? #88

Open theoryshaw opened 2 years ago

theoryshaw commented 2 years ago

Is it possible to get IFC standards development to be quicker and more agile?

Projects such as FreeCAD and BlenderBIM rely heavily on the IFC format, mainly through IfcOpenShell. In fact, BlenderBIM's native file 'is' the IFC file.

Although there's many advantages to this, there's also a lot of disadvantages. The main disadvantage is that certain types of functionality, very common to many BIM platforms, do not have an equivalent counterpart in the schema.

Functionality such as...

...to name a few.

Since there's no current schema that accommodates these types of functions, coders create this functionality in the native program. Since it's unique to the particular authoring program, the opportunity for true interoperability is lost.

Once this functionally is 'baked' into the native program there's very little incentive to find ways to translate it to a future IFC schema that will eventually accommodate it. Which, often times, by that time it's available, more bells and whistles have been added to this core functionality, so the lack of incentive continues and the gap continues.

If we could find a way to make standards development as agile as open source development is, I think it would make IFC adoption more robust and commonplace.

Granted such an approach to standards development would be messy and seemly chaotic, as is open source development, a lot of times, is. But it's exactly this ability of users not having to ask permission, and just creating what they think is a good idea, that allows such a rich functionality.

In the end, if it's not a good idea, it will not be adopted by others, and will wither on the vine. Taking an evolutionary analogy, it will not be selected for. But it's exactly this ability to act on these seeds of thought, like genetic mutations, that provides such a rich foundation of innovation.

So what would such an open approach to standards development look like? Thoughts?

stefkeB commented 2 years ago

I can only support this idea when the development of IFC is split into a core and stable, reviewed part which is standardized at ISO and CEN and a more fluent part where experiments may happen, but which don’t just flow into the ISO version… One reason being that an official standardized version needs to go through quite some reviews and balloting before publication AND publication as CEN standard automatically turns it onto national standards.

theoryshaw commented 2 years ago

I think that's a good idea. Could actually see how these reviews and balloting could be augmented by a demonstration of how much the fledgling standard is being used in the wild. Actually, could see demonstrated use, as a more accurate measure of how robust the standard is, over the reviews and/or balloting of an a priori proposed standard.

TimSharrock commented 2 years ago

On the other side - as a rather slow-moving implementer we would struggle to keep up with lots of changes to IFC files that we would expected to import. If it was guaranteed that there would always be "add ons" rather than replacement for the basic geometry we could just ignore extra bits unless there was a particular business case to support the extras. For example, if we did not implement some parametrics, we could at least get a facetted approximation.

Moult commented 2 years ago

I apologise I missed this thread and didn't reply earlier.

For IFC4.3, there is a process outlined here: https://github.com/buildingSMART/IFC4.3.x-development/wiki/IFC-4.3.x-Change-Process (note the teams are a bit outdated, so feel free to join in your area of expertise! )

In short, there are a series of domain specific teams - those who have an intimate knowledge of the domain, or are intimately familiar with the schema's implementation of that domain. Here's the rough process (copied from the link):

  1. Anybody can submit Github bugreports
  2. Allocated to a domain team to review
  3. Turned into a formal proposal (exactly what is changed in schema, etc) with community discission
  4. Allocated team makes a decision to approve / reject
  5. Implemented (exactly how it is implemented now is still tricky - docs are now in Markdown thus reducing the barrier to entry) but schema changes are still going through an app, though work is being done to make it so that anyone can text edit or UML model in any app.

Then there are some automated QA checks after that. Everybody can join in, and anybody can read the discussions. It's a relatively new process, but I reckon it has potential.

@stefkeB and @TimSharrock to address core and stable, this is the reason there is a core review team. They are those who understand the aspects of the schema which have far-reaching consequences and can guard against these types of problems. Also, I believe certain attributes are being migrated to psets where they are more nimble, and the core can remain more stable.

@theoryshaw I think implementing is starting to happen alongside development - I've certainly been doing so alongside the texture proposals I'm been working on. I think IfcRail has been too in their unit tests.

theoryshaw commented 2 years ago

"Granted I come from companies that developed “proprietary” software, but never in any conversation did we say “what’s the open source schema that we can model our database on?” It was more like “We need to implement curves by Friday!”" - Ian Keough

theoryshaw commented 1 year ago

IFC's current license, would also make this agile way of working impossible, it would seem, as well.

No derivatives: "If you remix, transform, or build upon the material, you may not distribute the modified material."