X3D Ambitions

After spending more time trying to understand the X3D spec, I think I've decided that it is simultaneously less ambitious and more ambitious than I had expected. I had initially thought that X3D intended to define specifications for a lot of the annoying 3D programming issues like file exchange, scene graphs, etc. This way, programmers could just use some X3D components instead of having to code their own lower layer 3d code. Based on what I had read from the spec and about the history of X3D, I thought that that's what X3D was for. I'm a little skeptical of that idea, but it does sound intriguing. I'm actually a little disappointed that this isn't wasn't X3D was aiming to do. In fact, X3D seems to be just a standard for a 3d media player/browser. They've essentially designed a file format for X3D media and an API for talking with X3D browsers. If X3D were a database, the X3D specification would describe the file format of the database, an RPC framework for communicating with the database, and a general description of how the database should behave. This is an ambitious vision, but it isn't as generally useful as having a bunch of lower-level components. Hopefully when the 3D Industry Forum comes out with their competing spec, it'll be possible to compare which approach is more useful. I suppose that it's like the difference between white-box and black-box inheritance. Oh well.

In any case, generating code using XSLT seems to work pretty well. It's a little verbose, and you have to watch for those <> characters in the code, but I've been pretty satisfied so far. Hopefully, if all goes according to plan, I'll have a rudimentary partial implementation of a few nodes from the SAI layer of X3D by Monday. Then I can actually start cobbling together a renderer and parser.