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@xxxxxxxxxxxxxx
For additional commands, e-mail: batik-users-help@xxxxxxxxxxxxxx
|
