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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
