xmlgraphics-batik-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giles <gi...@oz.net>
Subject Re: GVTBuilder error with custom DOMs
Date Sun, 17 Mar 2002 17:27:18 GMT
Justin Couch wrote:

>Chris Lilley wrote:
>>JC> the W3C folks they keep telling us "X3D is trying to solve the same 
>>JC> problems as SVG - SVG does it, why can't you".
>>I would appreciate a reference to who said that, and when.
>Persistent theme since at least mid last year. I was in one halway 
>meeting at Siggraph last year that involved 7 or 8 people, I don't 
>remember names now. Since then, the Web3d people that also go to the W3C 
>meetings have consistently reported this. The main two that I know from 
>the web3d side are Don Brutzman and Joe Williams. In addition, my 
>business partner was at the Web3d conference in late feb and had a very 
>long conversation with someone. IIRC it was Evan Ireland, but I'll have 
>to check on that.
A brief introduction.  I'm Alan Hudson, the other lead on the Xj3D 
project, and typically the more politc member :)  I'm sure you've all 
meet Justin Couch by now.

In regards to W3C, we had a good presentation of SVG and chat with Ivan 
Herman(not Evan Ireland) from W3C at our last web3d symposium.  His view 
was that the issues that SVG and X3D face are very similar.  The 
requirements of rendering a real-time scenegraph are hard and they are 
pushing the XML document model pretty far.  I found myself constantly 
shaking my head in agreement as he described the challenges SVG faced 
and the solutions proposed.  I'm definately interested in the ins and 
outs of the SVG DOM specification.  We have similar scripting 
requirements which a standard DOM implementation will not handle.  That 
said, I hope that all XML languages will interoperate at some level with 
a standard DOM.  

One of the reasons we need our own layer above DOM is for effeciency. 
 Passing string representations of field values is unreasonable for some 
of our datatypes.  An example would be a coordinate set for a human. 
 Its not unusual for X3D programs to animate every vertex each frame for 
an animated human.  If we had to represent this data as a string and 
then parse it each frame well, there goes real-time performance.  So we 
have extra methods which allow you to represent datatypes in there more 
natural form(like float arrays).  But, we do allow access to these 
fields with their string counterparts.  So we can hand a standard DOM to 
someone and they can access the fields.   It may not be the most 
effecient, but it would work.  Our standard example is someone might use 
this interface to turn on a lightbulb, but not to animate a human.  Is 
this the type of reason you needed a layer above the DOM?  I've seen 
references to conformance issues.  Are you stating that someone cannot 
build and modify an SVG document via the DOM but must use SVG DOM.  Or 
is it just faster, more feature rich to use the SVG DOM?

Alan Hudson
President: Yumetech, Inc.                      http://www.yumetech.com/
Web3D Open Source Chair        http://www.web3d.org/TaskGroups/source/

To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org

View raw message