[ODE] XML ODE Data Interchange Format

[William Denniss]

Hi All,

Driven by my own need for importing an ODE scene described by XML, I
have developed a draft XML ODE format named 'XODE' which I am proposing
as a standard and request comments.  I plan to use it with the ODEEd ode
editor (as it enables developers to write custom import and export
plugins) - but the design goal is for a generic, interoperable and
extensible standard that could be used in any ODE designer and
application.

I'm not DTD expert and have not written a DTD for it yet.  Regardless it
would be a waste of time until any issues with the format have been
ironed out.  I have written a fairly detailed specification, with an
example file.

The document is located here:   http://tankammo.com/xode/xode.txt

Please review it and tell me if you think it is suitable for describing
an ODE scene, and if you are the author of an editor if you think it
would be feasible to support (even if initial support was export-only -
as that is much easier due to not requiring an XML library).


There were a few design decisions that I have made and I'll briefly
outline them here so that you know where I am coming from (the document
also has some information).

Based on what I have seen in the current breed of editors and of ODE
itself, I took the view that the ODE scene is generally broken into
three components - the bodies (ie. physics objects), geom (ie. collision
objects) and 3D meshes.  The first two are standard but the last can
vary enormously between editors and projects.  Therefore I did not
attempt to define the display components at all, and simply have a
"mesh" tag with a name, position and scale.  It is then up to the
importer to determine how to interpret the name (and actually get the
data) - or to use an extension.

Every XODE tag can contain an "<ext>" extension tag.  In this manner -
programmers and ODE editors can store any extra information they need. 
Importers and Exporters are requested to honour that tag and preserve
it's data even if they can't understand it.

I chose a tree structure over a flat listing as it feels more natural to
XML.  Hypothetically, each body, geom and mesh could be listed one after
the other with a "link" attribute to govern which body a geom belongs
too (and so on), but instead I designed it so that geoms which belong to
a body are listed as child tags to that body.  This couldn't work for
joints (which can link two bodies) so they are "flat" listed.  If I
didn't use this tree structure, then XML isn't necessary - but it seems
more intuitive this way as scenegraphs are invariably tree-like, XML can
be more extensible and the files are more friendly to human review.

I also added a new container object which doesn't have any
representation in ODE and that is a "group".  Like worlds - the group
can be used to store bodies, geoms and meshes - but unlike worlds it has
no effect on the resulting ODE setup.  They exist purely because I
believe that some people and the editors may have a use for them.  For
example it may be helpful in a project to have all of the wheels of a
car grouped for whatever reason.  Importers can choose to ignore the
groupings (but not the objects within) or not as appropriate.

I await your comments.

Regards,

Will.


---
William Denniss - will@ http://tanksoftware.com/