This doesn't really seem like the right abstraction. 3D models are inherently interactive. There could be some value in supporting 3D video, where interaction

This doesn't really seem like the right abstraction. 3D models are inherently interactive. There could be some value in supporting 3D video, where interaction is inherently limited to 3 degrees of freedom. There may even be value to the "videos" being represented as 3D scenes with animation i.e. rendered on the device. However, "models" are something you need to interact with. To achieve an even remotely acceptable level of UX those interactions absolutely need to be custom tailored for the content. Let's say you want to display a 3D building interior. If you're going to allow any form of free camera movement, you need to define how that logic works. Do we want first person walk-through? If so, you need collision detection. For simplicity, let's assume you can walk through walls. However, at the very least you'll want to walk on the floor. What about split levels and stairs? No. That sounds too hard. We'll rule out walk-through. We've now got a floating camera, and it'll happily pass through any geometry. Now, should the camera orbit around a point, or is a first-person flying camera more appropriate? Wait, how fast should the camera even move when you indicate you wish to move forward? Okay, let's make that configurable. What if you have two points of interest and a large gap in between? How do we get from one area to other? Should the camera travel faster in this area? Should there be some standard mechanism to jump to another location in the scene? Hmm, too hard. Let's ignore that problem for now. Should there be constraints with respect to how far you can zoom in and out? I guess we could define that in the file somehow. Okay. Animation tracks. They were mentioned. Do they all auto-play? Is that going to be performant? What if we want to trigger animation tracks based on camera location or some other event? We'll need, like a DOM, I guess? > while we are not proposing a DOM for the data at the moment, we expect to in the future Ah, right. Well. Let's assume in the future there's a DOM. Wait? How do we interact with the DOM? JavaScript somewhere? Where are we collecting user events from to drive this interaction? Can we display UIs within the 3D scene and receive events? How do we build those UIs? This snowballs real fast. The solution you're going to end up with is WebGL/WebGPU. Anything less than that is far too restrictive and going to make for a terrible user experience.