[x3d-public] dual use of script tag in HTML environment

[Leonard Daly]

On 11/11/2016 11:16 AM, Andreas Plesch wrote:
>
>
>     >
>     > The implication for x3d spec. is that it would be better to have the
>     > field definitions in an attribute rather as in child nodes.
>     Something like
>     > <script ... fields=' "inputOnly SFBool isOver" "outputOnly SFColor
>     > diffuseColor_changed" '>
>     > That would be also more concise.
>
>     This would get really messy if a field were inputOnly MFString and you
>     needed to specify multiple values in form '"v1" "v2" "v3" ...'.
>     Also if
>     there are a lot of fields, especially with a large collection of
>     values
>     (e.g., MFVec3D) you could run into attribute value character
>     limitations.
>
>
> I had a feeling that this was already discussed at length, probably at 
> the
> time when the xml encoding was developed.
>
> To clarify, the MFString case would be fields=' "inputOnly MFString 
> myString ' "a" "b" "c" ' " "nextField" '

All internal single-quote marks would need to be escaped or converted to 
HTML entities. As you have it above, the attribute's (fields) value is ' 
"inputOnly MFString myString ', then with a bunch of quoted characters 
that are neither attributes nor values. It would need to be something like:

fields=' "inputOnly MFString myString '"a" "b" 
"c"'" "next-field..." '



>
> where ' "a" "b" "c" ' is the initialValue of myString .
>
> This is indeed quite messy and hard to parse. The only way around that I
> can think of is to not be able to specify initialValues explicitly. 
> Instead, common
> default values for each type would be defined, and scripts required to 
> initialize
> to other values if necessary. This is a deeper change but I would say 
> it is more natural
> to initialize field values in the script.

There is an "initialize()" method where this could be done; but that 
means putting data into code, and probably preventing reuse of the code.


>
> If limitations to the length of attribute values would be a concern, 
> they would need
> to be a concern for the <field> nodes as well as for MFVec3f fields in 
> general
> which need to have long lists for complex geometries. If there is a 
> situation
> where this limitation plays a role, the script itself could initialize 
> to long values.

HTML4 had a limitation of 65K, but HTML5 has no theoretical limit. My 
initial concern should not be a consideration in the evaluation of the idea.


>     If X3D is to be declarative, then all programming nodes (i.e., Script
>     and Shader) should be eliminated and new nodes added that provide for
>     the most commonly needed features.
>
>
> The existence of the script node points to an observation that often a 
> mix of declarative and
> imperative programming is desired by many.

I did not mean to imply that imperative programming is not useful, not 
vitally important to declarative programming. For example, look at how 
much JavaScript is used with HTML to make a far superior maintainable 
user experience than could be available with either one. JavaScript is 
separated from the HTML. HTML can trigger Javascript processing and 
Javascript can change HTML. X3D ties the declarative and imperative 
closer together. Imperative code is frequently an integral part of 
updating the scene, but so is the declarative part (TimeSensor + 
interpolators). Non-scripted HTML is static (with the exception of 
certain CSS effects), while non-scripted X3D may be dynamic.


>
> Currently, in cobweb the script node has the benefit of being part of 
> the event cascade
> which is mostly useful for time accurate simulations, eg. a script can 
> rely on the timestamp
> and that all other elements of the world are synchronized to that 
> exact timestamp.
> Another benefit is that it performs a little better than DOM scripts 
> which need to go through
> the DOM but not better than external scripts which use the SAI without 
> going through the
> DOM.
>
> Custom shaders need to be in the form of webgl programs. x3dom has
> http://doc.x3dom.org/author/Shaders/CommonSurfaceShader.html
> which is attempt to capture the most commonly used shaders in a few 
> parameters.
> But I feel that many shader users would want to go beyond that.
>
>     Programmatic access and support can be added through new capabilities
>     that allow scripts to access scene information, but not be
>     controlled by
>     the event system. Perhaps some nodes that convert events back and
>     forth
>     to direct access would solve much of the problem.
>
>
> That sounds interesting. Did you start to think about something more 
> specific ?

The idea came to me while writing the email. I'll start a new thread on 
the topic of events to explore that.


-- 
*Leonard Daly*
3D Systems & Cloud Consultant
LA ACM SIGGRAPH Chair
President, Daly Realism - /Creating the Future/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20161111/2c8b829f/attachment.html>