Counterproposal: let's add a new element <visible-complicated-stuff>. It accepts <source> children. You can do <visible-complicated-stuff interactive> and it does... interactive stuff of some sort, but nothing that could be visible from JS because that would leak privacy info, so really it would get direct mouse/keyboard/camera input and do something with it according to the vast list of standardized possibilities. Which would be length 1, because any more than that would be an interoperability nightmare. We'll give it the MIME type "application/stuff+interactive".
The source data would be interpreted according to its own vast list of standardized possibilities, which realistically would have a 3D model format subset of size zero because 3D formats are so diverse and cater to such different needs that etching one in stone for standardization is kinda silly. But we can pretend it'll be size 1. In which case the subtly differing implementations of lighting, texturing, potentially rigging, etc. will make it nonportable for the next decade or so, at which time we'll have a common-denominator format a decade out of date. But at least we called it "stuff" instead of "model" because then you couldn't put a scene into it and $DEITY help you if you wanted to animate anything.
Ok, it's not a great counterproposal. But it doesn't feel like it's inferior to the proposed <model> in any way, and has the advantage of being slightly more honest with its naming.
The only way I could take this proposal seriously is if it set out up-front to define an extremely limited subset of capabilities that are broadly useful. Something like <triangles> with a 'camera' attribute and <lighting> children or something. Then you could evaluate various file formats for suitability. But I just don't see any simplistic subset that would make any two groups of people happy. Everyone needs a tiny bit of additional capability for their use case. This is not a subsettable problem.
The source data would be interpreted according to its own vast list of standardized possibilities, which realistically would have a 3D model format subset of size zero because 3D formats are so diverse and cater to such different needs that etching one in stone for standardization is kinda silly. But we can pretend it'll be size 1. In which case the subtly differing implementations of lighting, texturing, potentially rigging, etc. will make it nonportable for the next decade or so, at which time we'll have a common-denominator format a decade out of date. But at least we called it "stuff" instead of "model" because then you couldn't put a scene into it and $DEITY help you if you wanted to animate anything.
Ok, it's not a great counterproposal. But it doesn't feel like it's inferior to the proposed <model> in any way, and has the advantage of being slightly more honest with its naming.
The only way I could take this proposal seriously is if it set out up-front to define an extremely limited subset of capabilities that are broadly useful. Something like <triangles> with a 'camera' attribute and <lighting> children or something. Then you could evaluate various file formats for suitability. But I just don't see any simplistic subset that would make any two groups of people happy. Everyone needs a tiny bit of additional capability for their use case. This is not a subsettable problem.