<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Edited to try to focus on comments that
have a response.<br>
<br>
<br>
<br>
</div>
<blockquote cite="mid:4d39193e-473c-4af5-e653-eda75ee70bb1@nps.edu"
type="cite">On 8/28/2016 9:32 PM, Leonard Daly wrote:
<br>
<blockquote type="cite">catching up....
<br>
<br>
<blockquote type="cite">Thanks for your continuing efforts.
Feedback:
<br>
<br>
a. Not clear what your motivation is. What functionality does
a Macro node provide that isn't already available using Script
and Prototype definitions? Getting clear about differences
helps getting clear about goals.
<br>
</blockquote>
<br>
X3D Script is not available in HTML as it is already being used.
<br>
</blockquote>
<br>
The X3D Script node is not the same as the HTML script element.
So there is no collision, only the need for precision when
discussing it. Both coexist nicely already, as they have for two
decades.
<br>
</blockquote>
<br>
They exists in different spaces because X3D browsers that run in a
web page (e.g., BS Contact) run as a plugin. X3D Script node never
exists in HTML space because the name is the same (at least to an
HTML parser) and the syntax is different.<br>
<br>
<br>
<br>
<blockquote cite="mid:4d39193e-473c-4af5-e653-eda75ee70bb1@nps.edu"
type="cite">
<br>
The Scene Authoring Interface (SAI) efforts for X3D (probably
v3.0) was able to successfully reconcile differences in JavaScript
and Java that were necessary under the VRML97 External Authoring
Interface (EAI). In that way, the same class structures and
programming patterns were usable in author source code - an author
could write the same kind of X3D-related source code in JavaScript
or Java, with event updates and field updates still working
consistently.
<br>
<br>
Among multiple reasons, it is also good to note that HTML5
explicitly supports the <object> tag for plugins, so we can
expect that the consistency of SAI is likely to still work across
various forms of invocation. As ever, exploration and testing is
advisable.
<br>
<br>
<blockquote type="cite">After repeated requests to X3D and
X3D-Public mailing lists, no one could supply an example of a
trivial PROTO (one without a Script node) that was not
convenience definition.
<br>
</blockquote>
<br>
I repeatedly provided the Universal Media Materials examples in
response to your request, both on the email list and I also
believe it came up during a teleconference.
<br>
<br>
These are found in the X3D Basic Examples archives.
<br>
<br>
<a class="moz-txt-link-freetext" href="http://www.web3d.org/x3d/content/examples/Basic/UniversalMediaMaterials">http://www.web3d.org/x3d/content/examples/Basic/UniversalMediaMaterials</a>
<br>
<br>
Sample declaration:
<br>
<br>
<ProtoDeclare name='ArtDeco00' appinfo='UniversalMediaMaterials
prototype' documentation='
<a class="moz-txt-link-freetext" href="http://www.web3d.org/x3d/content/examples/Basic/UniversalMediaMaterials">http://www.web3d.org/x3d/content/examples/Basic/UniversalMediaMaterials</a>
'>
<br>
<ProtoBody>
<br>
<Material ambientIntensity='0.25'
diffuseColor='0.282435 0.085159 0.134462' shininess='0.127273'
specularColor='0.276305 0.11431 0.139857'/>
<br>
</ProtoBody>
<br>
</ProtoDeclare>
<br>
</blockquote>
<br>
Unless I am serious missing something, this PROTO is a convenience
definition (labeling) of a specific material with the name
'ArtDec00'. <br>
<br>
<br>
<br>
<blockquote cite="mid:4d39193e-473c-4af5-e653-eda75ee70bb1@nps.edu"
type="cite">
<br>
Another interesting scene that does not include a Script node can
be found in the same directory:
<br>
<br>
<a class="moz-txt-link-freetext" href="http://x3dgraphics.com/examples/X3dForWebAuthors/Chapter14-Prototypes/HeadsUpDisplayPrototype.x3d">http://x3dgraphics.com/examples/X3dForWebAuthors/Chapter14-Prototypes/HeadsUpDisplayPrototype.x3d</a>
<br>
<a class="moz-txt-link-freetext" href="http://x3dgraphics.com/examples/X3dForWebAuthors/Chapter14-Prototypes/HeadsUpDisplayPrototype.html">http://x3dgraphics.com/examples/X3dForWebAuthors/Chapter14-Prototypes/HeadsUpDisplayPrototype.html</a>
<br>
<br>
<a class="moz-txt-link-freetext" href="http://x3dgraphics.com/examples/X3dForWebAuthors/Chapter14-Prototypes/HeadsUpDisplayExample.x3d">http://x3dgraphics.com/examples/X3dForWebAuthors/Chapter14-Prototypes/HeadsUpDisplayExample.x3d</a>
<br>
<a class="moz-txt-link-freetext" href="http://x3dgraphics.com/examples/X3dForWebAuthors/Chapter14-Prototypes/HeadsUpDisplayExample.html">http://x3dgraphics.com/examples/X3dForWebAuthors/Chapter14-Prototypes/HeadsUpDisplayExample.html</a>
<br>
<br>
</blockquote>
<br>
HeadsUp displays are a more interesting case; however, this is
better handled in HTML because it is easier to do so. <br>
<br>
<blockquote cite="mid:4d39193e-473c-4af5-e653-eda75ee70bb1@nps.edu"
type="cite">Looks like 5 more examples (5deepinternalroute.x3d
5deepnesting.x3d def.x3d route_inside.x3d and simple.x3d) can be
found in
<br>
<br>
X3D Example Archives: Conformance Nist, Miscellaneous, PROTO.
<br>
<a class="moz-txt-link-freetext" href="http://www.web3d.org/x3d/content/examples/ConformanceNist/Miscellaneous/PROTO">http://www.web3d.org/x3d/content/examples/ConformanceNist/Miscellaneous/PROTO</a>
<br>
<br>
Eight more scenes appear in
<br>
<br>
X3D Example Archives: VRML 2.0 Sourcebook, Chapter 31 -
Prototypes
<br>
<a class="moz-txt-link-freetext" href="http://www.web3d.org/x3d/content/examples/Vrml2.0Sourcebook/Chapter31-Prototypes/">http://www.web3d.org/x3d/content/examples/Vrml2.0Sourcebook/Chapter31-Prototypes/</a>
<br>
<br>
Of those, most do no include Script. Perhaps of special interest
is the SpinGroup prototype, which was originally proposed as a
VRML node. Demonstrating this node as a prototype in VRML showed
that specification addition was not necessary. The term commonly
used in those days was "avoiding node bloat" to keep the VRML
vocabulary as concise as possible, i.e. avoiding the addition of
duplicative nodes.
<br>
<br>
<blockquote type="cite">I felt that the ability to define a set of
nodes at initialization (parse-type) was useful. I added the
ability to vary the parameters from one instance to the next as
important to provide variability in the scene.
<br>
</blockquote>
<br>
ProtoDeclare field declarations, and ProtoInstance fieldValue
instances, can contain either simple types (MFVec3f etc.) or
SF/MFNode initializations.
<br>
<br>
Thus prototypes have full expressivity to extend any node
functionality in X3D.
<br>
<br>
ProtoInstance fieldValue insertions would be the right place to
vary parameters from one instance to the next.
<br>
<br>
Similarly Inline IMPORT/EXPORT can pass initialization values that
are either simple types or node types, as singletons or as arrays.
<br>
<br>
Hence the questions regarding how Macro compares and contrasts.
Differences hold the greatest interest.
<br>
</blockquote>
<br>
In this implementation Macros add the nodes to the namescope of the
Macro node. This does not happen for Inline nor PROTO.<br>
<br>
<br>
<blockquote cite="mid:4d39193e-473c-4af5-e653-eda75ee70bb1@nps.edu"
type="cite">
<br>
<blockquote type="cite">
<blockquote type="cite">c. Previous efforts on NetworkSensor
node, and the difficulties encountered, may be worth
considering:
<br>
<br>
<a class="moz-txt-link-freetext" href="http://www.web3d.org/x3d/content/examples/Basic/Networking/">http://www.web3d.org/x3d/content/examples/Basic/Networking/</a>
<br>
<a class="moz-txt-link-freetext" href="http://www.web3d.org/x3d/content/examples/Basic/Networking/NetworkSensorConnectionPrototypes.x3d">http://www.web3d.org/x3d/content/examples/Basic/Networking/NetworkSensorConnectionPrototypes.x3d</a><br>
<a class="moz-txt-link-freetext" href="http://www.web3d.org/x3d/content/examples/Basic/Networking/NetworkSensorConnectionPrototypes.html">http://www.web3d.org/x3d/content/examples/Basic/Networking/NetworkSensorConnectionPrototypes.html</a><br>
<br>
<a class="moz-txt-link-freetext" href="http://www.web3d.org/x3d/content/examples/Basic/Networking/NetworkSensorConnectionNodes.html">http://www.web3d.org/x3d/content/examples/Basic/Networking/NetworkSensorConnectionNodes.html</a><br>
</blockquote>
<br>
Communication between users (networking) is a useful area to
investigate. I was involved in the previous attempt and remember
many of the difficulties and different approaches that the WG
had. In the end we were unable to define anything for the
specification because the problem scope was not sufficiently
well-defined and agreed-upon. Things in the HTML world have
changed considerably since then and it would probably be useful
to try to get that kind of communication going again. I do not
know if it is appropriate to put that in X3D or better to handle
external of X3D in (e.g.) WebRTC.
<br>
<br>
I do not understand why it was brought up here. It is not a
topic I brought up.
<br>
</blockquote>
<br>
Apologies for not expressing that relationship more clearly. The
topic pertains because NetworkSensor is similar to Prototype in
that a player needs to create custom scene-graph fields, just as
Prototype declarations do. Thus the design of NetworkSensor
(which has different goals that Macro) and its dynamic parameters
seems quite reasonable. Unfortunately no successful
implementations occurred because all of the prototype
implementations were inside player codebases and the
owners/principals didn't want to pursue it. Even so, given the
greater number of options now, someone might want to implement it.
<br>
<br>
Hopefully the lessons learned from dynamic creation of X3D content
by NetworkSensor can also inform your design.
<br>
</blockquote>
<br>
<br>
I do not believe it is appropriate for X3D to duplicate an existing
functionality (e.g., WebRTC). Developing a support library to share
(between browsers) various information, from scalar fields to node
sub-trees is probably a better way to go.<br>
<br>
<br>
<p><br>
</p>
<div class="moz-signature">-- <br>
<font class="tahoma,arial,helvetica san serif" color="#333366">
<font size="+1"><b>Leonard Daly</b></font><br>
X3D Co-Chair<br>
Cloud Consultant<br>
President, Daly Realism - <i>Creating the Future</i>
</font></div>
</body>
</html>