[X3D-Public] Fwd: Re: [X3D] X3D HTML5 meeting discussions:Declarative 3D interest group at W3C

[Dmitri Rubinstein]

Hi,
> I believe you misunderstood some basic pricibles. Both systems
> have WebGL and Native implementations. XFlow is a (not yet
> publicly available) data Flow system which could sit on top of any data-contatiner.
> It should work with XML3D, X3DOM or anything else it could interface.

I actually see here a possibility to cooperate. IMHO, instead of 
discussing what is better XML3D or X3DOM try to figure out which 
features are basic to both and make some common spec so both XML3D and 
X3DOM can be implemented on top of it. What are the smallest building 
blocks ? For example X3DOM's IndexedFaceSet is too complicated but can 
be mapped to XML3D's mesh or something similar. We also need some data 
flow concept that is independent of DOM-events, so we can map it in the 
native implementation directly to GPU or use other acceleration 
techniques. X3DOM has ROUTEs, XML3D has Xflow. What can be implemented 
on top of what ? Or can be there something inbetween ? So I would prefer 
to see ideas for the lowest common denominator for declarative 3D on a Web.

At least it is clear that it need to be a scene graph. Internally it 
need to be a DAG, at least partially, since geometry need to be reused. 
When subgraphs need to be referenced, and demand is a question of good 
user case scenarios, then good ideas for proper CSS handling should be 
proposed.