Just released RXSD (via github), a XSD <-> Ruby classes translator that makes use of Ruby's runtime introspection / reflection mechanisms to convert XML Schema Definitions to Ruby classes on the fly. Also supported is generating string Ruby class definitions (to be subsequently written to the filesystem) as well as a XSD metadata library / extendable builder interface to add output support for whatever language you need (python, c++, java, xml and other various formats, etc).
It's still pretty rough around the edges, I whipped it up in a little under a month (licensed under the LGPLv3+, so feel free to use it in proprietary apps, just make sure to publish the changes to RXSD itself back upstream), but most of whats there should be working. I'm going to keep hacking at it, mainly in part of a couple other things I'm doing, but also to improve features / support all around. This is my first project I'm hosting on github, so we'll see how that goes, from what I've seen it's pretty cool though (makes it very easy to share changes back / forth between projects).
As always, have at it!
X3D (wikipedia) is one of those standards that is going to become very popular because it has a huge feature set or fail into obscurity because it is too large and complex to use. Regardless, I've just discovered the specification and have been reading about it / playing around w/ a few implementations over the last few days and I'm pretty impressed.
The cool thing about X3D is that it is a whole 3D scene standard, meaning not only does it encapsulate 3D meshes contained within traditional standards, it has practically everything you want for a 3D world. Lighting, Materials, Networking, Sound, Events, Animation, Scripting, Physics / Collision, and a slew of other 3D scene properties can be described in the X3D format. Of course the trade off for being this complete is the complexity of the standard.
The Draft Specifications and xsd go a long way to (starting to) understand the specification. At its root X3D is fairly straightforward, it is represented via xml files, created with a generator and parsed with a loader. Loaders do not run any of the dynamic / execution time components, rather a browser is used to manage scenes/scene graphs, the complete hierarchical set of all objects known as nodes. Nodes contain descriptive fields and events to manipulate and query the node state.
From there its just different node types which describe different types of components in the system. Components exist for 2D and 3D locations, coordinates, geometry, resources (audio, input, network, etc.), animation, collisions, navigation, organization, etc. Needless to say, alot of abstraction/inheritance is used, component interfaces sometimes expand several levels deep before concrete node object classes are defined. It's pretty complex but complete.
X3D itself is a successor of the VRML standard, the old VRML syntax is still supported as an alternative for xml. It's a relatively new standard, first approved in 2005, and at the very least an interesting study. I may continue to muck around with it, possibly using it in an new project in the future.