I saw the mention of COLLADA in the beginning, and prepared myself for the worst, and here it is.

Things I dislike about this:

0. Not a single editor looks like they write games/do web programming for a living. Their experience and expertise is questionable at best--and one of them is responsible for COLLADA.

1. We don't need shaders in our assets. Time and time again we find out that assets are fed into tech that's wildly changing, and having any prebaked assumptions about shading is a "Bad Idea (TM)". This format would be more useful, for example, if it didn't assume glsl, if it didn't assume multiple rendering passes, and so on.

2. Don't have an "extras" or "extension" section. There's no reason that it should take a long time to extend a format, especially if its tightly-scoped and simple to being with. Adding this flexibility here leads to issues with shoving in special data, lazy exporters, hard-to-write importers, and so on. Just no. Stop. That's why .OBJ has has such staying power--it is simple and non-extensible (barring weird shit like smuggling data into comments).

3. Schemas are silly in this use case. This is the Web, we don't really use schemas in our JSON. This is a practice pulled over from XML, and honestly one that just smells to me like "Oh, we had this in XML COLLADA...LETS DO IT IN JSON!!!!!one".

4. The material system is vague. It's an overly complicated wrapper for what, I assume, would normally just be a JSON object of param:value pairs. Better question: when would this ever be used in a real application? Hint: never. You want a simple mapping of faces to a material ID, and then maybe a separate definition of those materials in, say, a simple format (which is not what this spec does). Usually, you just punt to the rendering pipeline anyways.

5. They don't specify a binary format. This would be a useful thing to do, especially if paired with a decent reference parser. Punting that down to road means that they are forced to be overly generic in their notions of materials and animations and whatever else, without actually adding any value in terms of how to store the meat of the asset data.

6. Cameras are almost always determined by the application, and can be represented more compactly than they are here.

7. Optional and default values are the devil. No no no no. This format is intended for consumption by machines, and maybe by humans--if I have to read your spec to figure out why something is being set to what it is, I'm not going to use your format. Explicit >>> implicit for file formats.

~

I could go on, but why bother?

This just looks like a bad attempt to bring over the problems of COLLADA into JSON and then inflict it on web developers.

I'd much rather see people solving the problems that we actually have:

1. Make a simple binary/base64-wrapped format to handle static mesh geometry with material groups.

2. Make a simple binary/base64-wrapped format to handle animations and describe tracks. Go look at md5anim as a start.

3. Make a simple JSON format to describe a scene graph. Just nodes and translations.

4. Make a simple JSON format to describe all of the metadata associated with a scene--list of scene graph files, list of animation files, list of mesh files, list of materials files, and maybe grouped into device requirements (oh, on mobile, load this instead).

And so on. The idea is to have simple microformats that are straightforward to implement, standalone, and that compose nicely. COLLADA/glTF is not that.

Moreover, consider what we're trying to accomplish here: little dioramas and markup (ala VRML), or assets that are actually going to be reused in different applications as content atoms (like images or sounds are).