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

[Chris Marrin]

On Dec 30, 2010, at 10:27 PM, Len Bullard wrote:

>> For example if you don't use DEF or PROTO 
>> then you get a natural opening for CSS because the styled item is 
>> truely everywhere in the tree instead of just once on the graph.
> 
> What would replace the PROTO?
> 
> XML does not enable behavioral extensibility.  PROTOs do.

And so I think you need to go back to the drawing board and try to understand why protos exist. I know their genesis since we whiteboarded them in a lab at SGI in 1995 or so. We were trying to solve the problem of reusability. We were working in an environment without the support of an underlying object model. So we created one ourselves. We didn't have an underlying event system, so we created them ourselves. The same is true of sensors, interpolators and the entire complex timing model that is in X3D today. 

I think it's important to reset our conceptual model given the situation today. When we started WebGL, our informal charter was to not do anything that was not directly related to rendering 3D content. We originally included typed arrays because we needed them for VBO and related data representation. But we later removed them to their own spec because they are not specifically about 3D rendering. And an interesting synergy occurred. At least 3 other components of "HTML5" needed the same thing. So now Safari, Chrome and Firefox have compatible typed arrays which are starting to be used not just in WebGL, but in XHR, File IO, and in the Audio XG.

You might say that declarative 3D is not just about rendering, and you might be right. But it will serve you much better if you can separate rendering from the other needs, real or perceived, in the system. If you believe you need declarative interpolators, in what way does CSS animation not fit your needs? Maybe adding to CSS Animations is a better approach. Do you need a "way to route strongly typed data from node to node", or will the existing mechanisms in HTML be sufficient? Given Typed Arrays (for strong typing) and the existing DOM event and JavaScript mechanisms, can you build a system that perhaps has even more flexibility than the current system and would be useful to other modules in the browsers?

Sensors are another area which were added because we had to add EVERYTHING. HTML has a rich event model which currently includes keyboard and mouse events. And modules are emerging to support touch gestures and accelerometer data.

I understand this is all very different from the thinking of the last 15 years. But setting your sights on a simpler and more focused set of features could be the best way to get a toehold in the browsers and go from there.

-----
~Chris
chris at marrin.com