[ODE] XML

[Anselm Hook]

Another idea (that was pointed out to me today) is that C# (such as from
the go-mono project) could be used to get the reflection of C++ types -
and be used to generate loaders and savers (that run in ordinary C or
C++)...  not sure if mono supports managed C++ but this would be ideal.

> I guess the only part we're missing is the Control Interface Mapping.
> For example how do we indicate how your code should use the ODE
> object. If it's a wheeled vehicle you might have a turn left \ right \
> forwards \ backwards requirement, but a hovercraft would also need
> strafe controls. How do you know how to manipulate the object to do
> this as the designer of the object intended. Should the ODE file even
> contain this information.

I see 2 parts to your question.

  1) describing what the relationships are
  2) procedural behavior to deliver on events

We are largely talking about declarative scene-graphs I assume...  So we
have to all recognize that this is not going to satisfy all users.  For
simulations that largely have dynamical objects, dynamic relationships and
which undergo significant changes in the number, type and behavior of
objects then a static declarative notation may not capture any useful part
of the application state.  Typically such applications are best expressed
with boring ordinary procedural code... (perhaps individual entities can
be declarative but the system overall is procedural) (IMHO).

That said - there are definately ways to deal with control interface
mapping for declarative simulations...

The first part - simply expressing the relationships is easy:

  1) VRML uses a ROUTE concept to express the relationship mapping...
this part of the issue can be solved that way.  Things have sockets and
routes... it is actually a bit clumsy.

  2) SoftImage uses a similar solution for their dataflow model.

The second part - expressing behavior is hard:

  1) VRML introduces SWITCH nodes and other behavior nodes for abstracting
"what" to do...  I don't know if this is the best way to try and capture
conditional/procedural behavior...  I feel the VRML way is wrong.

  2) A lightweight embeddable language can do the trick... again though I
feel this is wrong...  it is too much work for somebody to implement and
allows for too much complexity and variability in the format...  if the
format is not absolutely dirt simple then there are implementations whose
differences can be argued over endlessly rather than proven right or
wrong.

Also in any situation where you start to introduce procedural behavior
into the graph you start to have at least 2 graphs that interweave each
other - a basic scene-graph and a behavior-graph.  There are traversal
order issues that will crop up.  You might render in a certain order, but
have to traverse in some other order to do dataflow, or might have
dataflow loops that you cannot resolve.  You might have input points that
drive the graph, but also simulation points that have to run
autonomously...  it becomes a complicated mess.

One idea is maybe you could allow people to introduce their own nodes in
the graph that you simply ignore...  so (unlike VRML) people can extend
the system privately for their own use but the general standard is simply
a transport format for basic data.

Note that (again in my opinion) what we are talking about (in the big
picture) is nothing less than the highest level simulation grammer; it is
the point where the designer intersects the system.  Once there is a
powerful grammer and even rudimentary grammer authoring tools (such as a
text editor) then it becomes possible for non-technical folk to quickly
build out thousands of simulations of every flavor, color and charm.  So
if we can deliver this we should expect a much wider adoption of ODE.

 - a