[x3d-public] X3D V4 Draft Requirements Proposal -- Only Scripting

Joe D Williams joedwil at earthlink.net
Tue Mar 28 13:11:21 PDT 2017


>
> So until X3D becomes fully integrated in HTML and can be solely 
> scripted
> through DOM and does not need a JavaScript library to parse and 
> execute
> it, there is no point in talking about an X3D Script node.
>

Unless it is in an inline - then the parent x3d fragment should be 
able to deal with it just like any other stuff in an inline context, 
including scripts and prototypes.

Here the main idea is that a basic functionality can be obtained at 
the <x3d> level without allowing inlines. If inlines are allowed then 
it is a different level of complexity just due to the fact that for an 
inline, then either x3d3 or x3d4 would be allowed. x3d3 includes all 
encodings and the x3d v3 sai. For example, existing x3d 
implementations have a way, not quite standard in html, that manages 
to connect the dom to events in the inline.

Thanks,
"The best current answers will come from down-under."
Joe



----- Original Message ----- 
From: "Leonard Daly" <Leonard.Daly at realism.com>
To: "Don Brutzman" <brutzman at nps.edu>
Cc: "X3D Public" <x3d-public at web3d.org>
Sent: Tuesday, March 28, 2017 10:36 AM
Subject: Re: [x3d-public] X3D V4 Draft Requirements Proposal -- Only 
Scripting


> Only have time right now to respond to the first thing that caught 
> my
> attention...
>
>>
>> It's not clear that much much recent dialog is penetrating several
>> portions of your list.  For example, SVG also has a script node 
>> that
>> seems to operate just fine in combination with HTML.  It seems 
>> prudent
>> to pose interoperability as the baseline goal requirement, with the
>> corresponding due diligence to compare pros/cons and implement
>> alternatives.  Listing things like "nodes shall not have name
>> conflicts" and "shall behave as the HTML element" as end states 
>> seems
>> to close off such necessary consideration of alternative approaches
>> that already exist and can work.
>
> It has been repeated pointed out that SVG has a script node. It is
> called script. SVG is also part of HTML5 and fully integrated into 
> the
> DOM. Also SVG's script is a real JavaScript node that is accessible 
> from
> outside of the SVG tag set. In order to get X3D there, X3D would 
> need to
> be recognized as part of HTML and this would need to be regular
> JavaScript element. Based on everything I did in a quick read 
> (several
> pages from a Google search of 'SVG Script') this morning, you can 
> script
> SVG from inside or outside of the SVG tag.
>
> So until X3D becomes fully integrated in HTML and can be solely 
> scripted
> through DOM and does not need a JavaScript library to parse and 
> execute
> it, there is no point in talking about an X3D Script node.
>
> -- 
> *Leonard Daly*
> 3D Systems & Cloud Consultant
> LA ACM SIGGRAPH Chair
> President, Daly Realism - /Creating the Future/
>


--------------------------------------------------------------------------------


> _______________________________________________
> 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