[ODE] Fwd: Re: [Pyode-user] XODE

Bernie Roehl broehl at ecemail.uwaterloo.ca
Sun Jun 27 22:06:10 MST 2004


At 11:23 AM 6/28/2004 +1000, William Denniss wrote:
>The reason for the abstract <geom> is that the different shapes share many 
>properties so I decided to use an abstract <geom> element to simplify 
>writing a paraser.

The way I typically handle that is with subclasses.  For example, if I were 
to encounter a <geomSphere> element, I create a new instance of the 
geomSphere class and set its properties from the attributes of the 
element.  Some of those properties will of course be handled by the 
geomSphere class itself (such as the radius) while others are handled by 
the geom base class (such as the category bits, for example).  This makes 
it very, very easy to add additional types of geom -- each new subclass 
only has to worry about things that are specific to it, and leave 
everything else to the base class.

>  I thought the SAX parser would function something like this:
>
>* encountered <geom> element
>* encountered <transform> element - value read and stored
>* encountered geom shape element - ODE Geom object created (depending on 
>specified shape)
>* encountered properties of the geom - calls made to ODE to set such 
>properties on the object using previously created Geom object

Yes, that's correct.

To me, that seems complex.  Having to store the values of the transform, 
for example, is extra overhead for the SAX-based parser.  Having to rely on 
the ordering of child nodes within the <geom> element is also risky, even 
though XML processors are supposed to preserve element ordering.  I would 
also prefer a one-to-one correspondence between elements and objects, 
rather than have <geom> elements be essentially "hints" to the parser that 
it should start keeping track of information for an upcoming sphere (or 
box, or whatever) node.

Perhaps I'm worrying about this too much.  What I would suggest is that Tim 
go ahead with writing his SAX-based XODE parser based on the current spec, 
and he can tell us whether it turns out to be easy or hard.  If it's hard, 
perhaps we can re-examine things.  And if it's easy, I'll shut up.  :-)

To me, that's always the best way -- try things out and see what works.


--
   Bernie Roehl
   University of Waterloo Dept of Electrical and Computer Engineering
   Mail: broehl at ecemail.uwaterloo.ca   Voice: (519) 888-4567 x 2607 [work]
   URL: http://ece.uwaterloo.ca/~broehl 



More information about the ODE mailing list