[ODE] XML

[Chris Brodie]

Good Post.

I tend to agree with all of your points(assuming I have no knowledge of VRML). The idea of 'custom' nodes is interesting and I'm sure any work on top of SXP could cater for unknown nodes in a kind manner(ie not throwing exceptions). I agree though that the system should cater directly to ODE core objects however, ie joints, spheres, bodies etc, etc.

I completly discount the use of c# for cross platform use, unless someone in the know can tell me if it can compile on to all of ODE's destination platforms.

Further points to consider:
-Using potentially custom nodes, can a dtd be used (or whatever the current equiv is. xsd?). I don't do voliation on my XML documents so I don't know exactly what the capabilities are here.
-Vague standards may be introduced by convention to allow the community to trade models with standard control systems, cars, motorbikes(Hovercraft!), etc. bipeds would be more complex but not impossible, etc, etc.

Perhaps about now we need a demo to promote discussion to find out what were not thnking about yet...

cb

> -----Original Message-----
> From: Anselm Hook [mailto:anselm@hook.org]
> Sent: Wednesday, 19 February 2003 12:57 PM
> To: Chris Brodie
> Cc: ode@q12.org
> Subject: RE: [ODE] XML
> 
> 
> 
> 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
> 
> 
> 
> 
> 


NOTICE
This e-mail and any attachments are confidential and may contain copyright material of Macquarie Bank or third parties. If you are not the intended recipient of this email you should not read, print, re-transmit, store or act in reliance on this e-mail or any attachments, and should destroy all copies of them. Macquarie Bank does not guarantee the integrity of any emails or any attached files. The views or opinions expressed are the author's own and may not reflect the views or opinions of Macquarie Bank.