<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 11/11/2016 11:16 AM, Andreas Plesch
wrote:<br>
</div>
<blockquote
cite="mid:CAKdk67uv1Of_GCx1Vpknn5r8yT_fuf5y=hQ91gAUAPzHjz374w@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex"><br>
><br>
> The implication for x3d spec. is that it would be
better to have the<br>
> field definitions in an attribute rather as in child
nodes. Something like<br>
> <script ... fields=' "inputOnly SFBool isOver"
"outputOnly SFColor<br>
> diffuseColor_changed" '><br>
> That would be also more concise.<br>
<br>
This would get really messy if a field were inputOnly
MFString and you<br>
needed to specify multiple values in form '"v1" "v2" "v3"
...'. Also if<br>
there are a lot of fields, especially with a large
collection of values<br>
(e.g., MFVec3D) you could run into attribute value
character limitations.<br>
</blockquote>
<div><br>
</div>
<div>I had a feeling that this was already discussed at
length, probably at the </div>
<div>time when the xml encoding was developed.</div>
<div><br>
</div>
<div>To clarify, the MFString case would be fields='
"inputOnly MFString myString ' "a" "b" "c" ' " "nextField"
'</div>
</div>
</div>
</div>
</blockquote>
<br>
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:<br>
<br>
fields=' "inputOnly MFString myString
'"a" "b"
"c"'" "next-field..." '<br>
<br>
<br>
<br>
<blockquote
cite="mid:CAKdk67uv1Of_GCx1Vpknn5r8yT_fuf5y=hQ91gAUAPzHjz374w@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<div>where ' "a" "b" "c" ' is the initialValue of myString .</div>
<div><br>
</div>
<div>This is indeed quite messy and hard to parse. The only
way around that I </div>
<div>can think of is to not be able to specify initialValues
explicitly. Instead, common</div>
<div>default values for each type would be defined, and
scripts required to initialize</div>
<div>to other values if necessary. This is a deeper change
but I would say it is more natural</div>
<div>to initialize field values in the script.</div>
</div>
</div>
</div>
</blockquote>
<br>
There is an "initialize()" method where this could be done; but that
means putting data into code, and probably preventing reuse of the
code.<br>
<br>
<br>
<blockquote
cite="mid:CAKdk67uv1Of_GCx1Vpknn5r8yT_fuf5y=hQ91gAUAPzHjz374w@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<div>If limitations to the length of attribute values would
be a concern, they would need</div>
<div>to be a concern for the <field> nodes as well as
for MFVec3f fields in general</div>
<div>which need to have long lists for complex geometries.
If there is a situation </div>
<div>where this limitation plays a role, the script itself
could initialize to long values.</div>
</div>
</div>
</div>
</blockquote>
<br>
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.<br>
<br>
<br>
<blockquote
cite="mid:CAKdk67uv1Of_GCx1Vpknn5r8yT_fuf5y=hQ91gAUAPzHjz374w@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
If X3D is to be declarative, then all programming nodes
(i.e., Script<br>
and Shader) should be eliminated and new nodes added that
provide for<br>
the most commonly needed features.<br>
</blockquote>
<div><br>
</div>
<div>The existence of the script node points to an
observation that often a mix of declarative and</div>
<div>imperative programming is desired by many.</div>
</div>
</div>
</div>
</blockquote>
<br>
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.<br>
<br>
<br>
<blockquote
cite="mid:CAKdk67uv1Of_GCx1Vpknn5r8yT_fuf5y=hQ91gAUAPzHjz374w@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<div>Currently, in cobweb the script node has the benefit of
being part of the event cascade</div>
<div>which is mostly useful for time accurate simulations,
eg. a script can rely on the timestamp</div>
<div>and that all other elements of the world are
synchronized to that exact timestamp.</div>
<div>Another benefit is that it performs a little better
than DOM scripts which need to go through</div>
<div>the DOM but not better than external scripts which use
the SAI without going through the</div>
<div>DOM.</div>
<div><br>
</div>
<div>Custom shaders need to be in the form of webgl
programs. x3dom has</div>
<div><a moz-do-not-send="true"
href="http://doc.x3dom.org/author/Shaders/CommonSurfaceShader.html">http://doc.x3dom.org/author/Shaders/CommonSurfaceShader.html</a></div>
<div>which is attempt to capture the most commonly used
shaders in a few parameters.</div>
<div>But I feel that many shader users would want to go
beyond that.</div>
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
Programmatic access and support can be added through new
capabilities<br>
that allow scripts to access scene information, but not be
controlled by<br>
the event system. Perhaps some nodes that convert events
back and forth<br>
to direct access would solve much of the problem.<br>
</blockquote>
<div><br>
</div>
<div>That sounds interesting. Did you start to think about
something more specific ?</div>
</div>
</div>
</div>
</blockquote>
<br>
The idea came to me while writing the email. I'll start a new thread
on the topic of events to explore that.<br>
<br>
<br>
<div class="moz-signature">-- <br>
<font class="tahoma,arial,helvetica san serif" color="#333366">
<font size="+1"><b>Leonard Daly</b></font><br>
3D Systems & Cloud Consultant<br>
LA ACM SIGGRAPH Chair<br>
President, Daly Realism - <i>Creating the Future</i>
</font></div>
</body>
</html>