So, if I get it right, there are no more generic Speckle representations for specific entity types (such as walls, beams, etc.), but rather a specific base type per host, where Speckle geometry + dict-based metadata live?
Right now, yes. DataObject inherits from the OG Base, which remains a dynamic object, meaning arbitrary properties can still exist outside the structured pattern. However, for user and developer friendliness, we generally recommend keeping things structured within the new top-tier object hierarchy.
This is where future specialization comes in.
For example, let’s say there’s a Wall schema similar to how v2 had SpeckleWall. If we define:
RevitWallinheriting from bothRevitObjectandSpeckleWall,- We get baseline consistency and strongly-typed classes.
That’s not just theoretical—it’s an extrapolation of where things are heading. I hope that makes sense!
Moving Between Native and Speckle Types
For sending and receiving, applications that support Multiplayer Modelling (as @clrkng has described elsewhere) will provide the best experience. However, the aim is that as many applications as possible will understand DataObjects—even if they don’t natively support something like a RevitInclinedCurvedWall.
In practice, this means:
- All Next Gen connectors will publish
DataObjects. - Where necessary, they’ll publish more nuanced versions per application.
- On receive:
- Some applications will use them contextually for coordination and collaboration.
- A few can translate a subset or superset of typed objects when there’s a common understanding (think Multiplayer Modelling workflows).
I don’t have a concrete timeline for you yet, but restructuring the zoo of object classes from v2 into something sustainable and scalable has been a necessary (and occasionally painful!) effort.
Hope that helps! Let me know if anything needs further clarification.
We have another line of comms for the COMPAS project, but thank you for asking this out in the open.