[X3D-Public] Fwd: Re: [X3D] X3D HTML5meetingdiscussions:Declarative 3D interest group at W3C

Philipp Slusallek slusallek at cs.uni-saarland.de
Thu Dec 30 23:03:31 PST 2010


Hi,

This is exactly what we are doing in XML3D. But the issues go much
deeper. One example:

What happens if someone deletes the referenced node? In X3D its still
there with all the other parents. Requiring this behavior to the DOM
will be a hard sell to the Web community -- as will likely be a push to
have some special cases for the 3D part. For one it would completely
change the memory management issues within a browser. But these options
remains to be discussed and alternatives to be evaluated.

In HTML the reference becomes a dangling reference that gets silently
ignored. This in turns violates a lot of inherent assumptions on the X3D
side. However, this behavior does not need to be a problem, unless you
want to ensure 100% X3D compatibility.

And we have not even talked about all the property inheritance, CSS
handling and such.

Things are not as easy as they sometimes seem to be.


	Philipp

Am 31.12.2010 07:40, schrieb John Carlson:
> If you can't fit a DAG into a tree, try using the for= attribute in  a node referring to an id= attribute in a node, similar to how some JSF frameworks work.  With JSF, we can build higher level abstractions that get compiled down to HTML and JavaScript, but still maintain XML for development.  That said, I find JSF obtuse.
> John
> On Dec 30, 2010, at 10:33 PM, Philipp Slusallek wrote:
> 
>> Hi,
>>
>> I do not think that we will ask the Web3D consortium to sanction
>> anything that the XG will come up with. But we have included it and this
>> list from the start to get your constructive input and feedback even
>> before the charter has been published.
>>
>> I believe this is a good and meaningful starting point, no?
>>
>> Because other attempts have failed does not mean that all of them will.
>> One could argue equally well that X3D has failed to get adopted in the
>> HTML world for 15 years, so we need to try different ideas. For example,
>> let's start at where the Web is today and add 3D to it while staying
>> true to their way of doing things instead of vice versa. There is no
>> principle that I know of that despite all its good points says that 3D
>> can only work the X3D way.
>>
>> If you do not believe that 3D in HTML is important, feel free to
>> completely ignore the initiative. If you think it is important then help
>> us resolve the very real issues of getting 3D into HTML/DOM with
>> constructive ideas and suggestions. Just putting X3D into HTML simply
>> does not work as easily as some people seem to think, so we have to do
>> things differently. Just how much differently, we have to see.
>>
>> X3DOM and XML3D are all out there with spec and everything to comment on
>> -- but please be specific.
>>
>>
>> 	Philipp
>>
>> Am 31.12.2010 00:09, schrieb Len Bullard:
>>> I hate to be blunt, Lauren, but I think there isn't a bats chance in hell
>>> they'll do that.  Bit between the teeth and all that.  So far, that's been
>>> the behavior we've seen for over fifteen years worth of 'new initiatives to
>>> create 3D standards for the web'.  They have all failed.
>>>
>>> Ever ask yourself why every attempt to replace X3D fails?
>>>
>>> The discussion always starts with two points:
>>>
>>> a) X3D low adoption means it has failed
>>> b) HTML models for 3D can be made general enough to do all the jobs X3D can
>>> do now.
>>>
>>> X3D is an order of magnitude too hard for HTML layout specialists to work
>>> with and they are the primary authors if the argument is composible
>>> compatibility with the HTML stack results in wider adoption (wider than what
>>> from a standing start: X3D of course).  The HTML part of the stack is
>>> irrelevant.  The Javascript/DOM isn't as you note.  CSS is the bear in the
>>> woods.  It is unclear to me how the CSS property system offers the X3D stack
>>> any advantages.
>>>
>>> I'm not for a moment suggesting the working group not proceed.  They may
>>> want to answer the question above first.
>>>
>>> len
>>>
>>> -----Original Message-----
>>> From: x3d-public-bounces at web3d.org [mailto:x3d-public-bounces at web3d.org] On
>>> Behalf Of GLG
>>> Sent: Thursday, December 30, 2010 3:55 PM
>>> To: x3d-public at web3d.org
>>> Subject: Re: [X3D-Public] Fwd: Re: [X3D] X3D
>>> HTML5meetingdiscussions:Declarative 3D interest group at W3C
>>>
>>>> If they give us a good DOM to play with.
>>>
>>> Yes, in theory. ::crossfingers:: And, of course, an accurate
>>> implementation of the X3D spec. Otherwise, this could get
>>> real messy in a hurry - this is no time for experimentation
>>> with 3D standards - I hope "they" will stick to the wisdom
>>> and the experience of the now tried and true, the
>>> interminable labor that resulted in what we know actually
>>> works and why. IMO any proposed changes to the spec should
>>> be referred to the Web3D Consortium for proper evaluation. I
>>> am sure glad good Consortium people are involved to help
>>> steer "things" in the right direction. Heck, it's about time
>>> I renew my membership (I hope others will too :). You guys
>>> need and deserve all the help you can get.
>>>
>>> Cheers,
>>> Lauren
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: Joe D Williams [mailto:joedwil at earthlink.net]
>>>> Sent: Thursday, December 30, 2010 3:12 PM
>>>> To: info at 3dnetproductions.com; x3d-public at web3d.org
>>>> Subject: Re: [X3D-Public] Fwd: Re: [X3D] X3D HTML5
>>>> meetingdiscussions:Declarative 3D interest group at W3C
>>>>
>>>>> Please don't ask me to do brain surgery with a spoon.
>>>>
>>>> Maybe some new tools? SInce the end objective must be to
>>>> represent the
>>>> element as a live scriptable DOM tree then lots of stuff
>>>> like passing
>>>> data to and from the embedded context and controlling
>>>> processing
>>>> within the thing may be easier or at least more familiar to
>>>> many If
>>>> they give us a good DOM to play with.
>>>> But heck we all know how easy it is to do easy stuff with
>>>> simple
>>>> animations and interactions. As len said
>>>> somewhen,"Rendering and
>>>> behavioral fidelity are equal requirements in these
>>>> systems". We now
>>>> see that it is relatively common to get similar rendering
>>>> fidelity
>>>> between platforms, even approaching 'realistic' high
>>>> fidelity in
>>>> appearance even when an appearance is complex. And, so it
>>>> will be with
>>>> fidelity for simple behaviours. Heck maybe all somebody has
>>>> to learn
>>>> is some 3DCSS.
>>>> When behaviors get complex and require synchronization to
>>>> achieve
>>>> fidelity, our mastery of the DOM event system will define
>>>> 'realistic'
>>>> to the user. Then, getting almost to what is needed for
>>>> real hifi fun
>>>> discover why the X3D SAI internal/external event system
>>>> works like it
>>>> does.
>>>>
>>>> Or, maybe some tech or practice that would shake up our
>>>> event system
>>>> 'pipeline' like shaders changed the rendering pipeline.
>>>> Joe
>>>
>>>
>>>
>>> _______________________________________________
>>> X3D-Public mailing list
>>> X3D-Public at web3d.org
>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>>>
>>>
>>> _______________________________________________
>>> X3D-Public mailing list
>>> X3D-Public at web3d.org
>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>>
>>
>> _______________________________________________
>> X3D-Public mailing list
>> X3D-Public at web3d.org
>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
> 




More information about the X3D-Public mailing list