[x3d-public] Nodes for V4 - Macro node, X3D scripts, HTML scripts, prototypes and ProtoExpander pattern

[Andreas Plesch]

I will intersperse short responses below.

On Aug 28, 2016 7:42 PM, "Don Brutzman" <brutzman at nps.edu> wrote:
>
> Thanks for the dialog Andreas.
>
> On 8/28/2016 2:42 PM, Andreas Plesch wrote:
>>
>> Hi Don,
>>
>> to me, the idea here is to be very pragmatic in order to make some
progress with html integration.
>>
>>     Date: Sun, 28 Aug 2016 11:57:37 -0700
>>     From: Don Brutzman <brutzman at nps.edu <mailto:brutzman at nps.edu>>
>>     To: Leonard Daly <web3d at realism.com <mailto:web3d at realism.com>>
>>     Cc: X3Dom Users <x3dom-users at lists.sourceforge.net <mailto:
x3dom-users at lists.sourceforge.net>>, X3D Public
>>             <x3d-public at web3d.org <mailto:x3d-public at web3d.org>>
>>     Subject: Re: [x3d-public] Nodes for V4
>>
>>     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.
>>
>>
>> I agree, the Macro node would offer nothing that is not already
available with Protos.
>
>
> Quite possibly, but i wasn't prejudging - simply wondering what was
different.  Just trying to understand the goals so that innovation can add
value.
>
> X3D + HTML capabilities are already quite rich.  Besides embedded
Prototypes containing Script nodes, additional approaches also include HTML
Script elements talking to an X3D object, and HTML-based JavaScript
libraries for that matter.

Yes, there are these traditional capabilities. My guess is that the Macro
node was designed to serve as a DOM element in the x3dom way of very tight
integration of x3d nodes as DOM elements.

>
> Given the diversity of this creation space, it is good to consider a
variety of possibilities.  Perhaps a Macro can add something new and useful.

To me, the most useful aspect is its simplicity.

>
>> The issue is, however, that in the foreseeable future Protos are not
actually available with x3dom.
>
>
> Actually I think that prototype support for X3DOM is much closer than
ever before.
>
> Am hoping to resume our group work on the PrototypeExpander pattern soon,
maybe next week.  The overall design pattern is somewhere above 90%
complete, we were working through special cases.  Given that John Carlson's
javascript implementation is far along already, then hooking it up as
preprocessor to X3DOM ought to be reasonably straightforward.  References:

Yes, the goal would need to be to have expansion by simply adding a js
expander to the web page with the scene.

>         thread: [x3d-public] Prototype Expander, Question on MFNode and
creating -material object in JSON. Issue for JSON schema
>         http://web3d.org/pipermail/x3d-public_web3d.org/2016-
July/004960.html
>
>         Prototype Expander design outline
>         http://web3d.org/pipermail/x3d-public_web3d.org/2016-
July/004982.html
>
>         update following discussion telcon
>         http://web3d.org/pipermail/x3d-public_web3d.org/2016-
July/005017.html
>
>         example result to check if design pattern works
>         http://x3dgraphics.com/examples/X3dForWebAuthors/
Chapter14-Prototypes/#MaterialModulatorPrototypeExpanded
>
>         http://x3dgraphics.com/examples/X3dForWebAuthors/
Chapter14-Prototypes/MaterialModulatorPrototypeExpanded.x3d
>         http://x3dgraphics.com/examples/X3dForWebAuthors/
Chapter14-Prototypes/MaterialModulatorPrototypeExpanded.html
>
> That manually created expansion handles ProtoDeclare, ProtoInterface
fields, ProtoBody, embedded Script with fields, IS/connect, ProtoInstance,
fieldValue, and internal ROUTEs.  The expanded version also works
identically in 6 of 9 browsers tested (with failures apparently related to
native JavaScript support, will keep checking).  The original source scene
is
>
>         http://x3dgraphics.com/examples/X3dForWebAuthors/
Chapter14-Prototypes/MaterialModulator.x3d
>         http://x3dgraphics.com/examples/X3dForWebAuthors/
Chapter14-Prototypes/MaterialModulator.html
>
> Still needed for design-pattern thoroughness: ROUTE external to
ProtoInstance, and ExternProtoDeclare.  Those are relatively easy, since
they just variations on what is there already.  Perhaps they are just
implementation issues; the design pattern seems pretty fully demonstrated.
>
> Once we agree that PrototypeExpander pattern is well-defined for all
manner of test cases, then I will write an XSLT version which will be
another prototype implementation.  Running against the 3800+ examples as
our test suite will shake out bugs (in code or content), just as it did for
X3D JSON Encoding development.

https://developer.mozilla.org/en-US/docs/Web/API/XSLTProcessor

With such a XSLT, it may be possible to have the browser do the expansion.
However, this only works with xhtml.

>
> Thus any of the PrototypeExpander implementations can be used as scene
postprocessors or parsing preprocessors in other tools.  Thus an X3D scene
that included prototype(s) would have a path to run in any X3D player,
whether it supported prototypes natively or not.
>
> So... once the expansion pattern is fully sorted out, seems like
PrototypeExpander can be a general solution option for tools and players.
Of course X3D players are likely to prefer their own native solutions as
more efficient, and a number exist already.  Whatever works, vive la
difference.
>
> Not to forget... Yet another straightforward path would be to look at the
JavaScript implementation supporting prototypes that is already in Cobweb,
perhaps adapting that for X3DOM.  Given the importance of both X3DOM and
Cobweb, similar code blocks are easier to maintain in tandem whenever
bugs/improvements are found.  Whatever works, cooperative competition is
always healthy.

>From what I can tell, there is little to suggest that much code or even any
can be shared between x3dom and Cobweb. They are just completely in
different worlds in their approaches.

>
>> To me it makes sense to give a node with a more narrow and simpler
functionality than Protos a distinct name and distinct semantics.
>
>
> Could well be.  It will be good to get some clear examples for further
consideration.
>
>> Even outside of x3dom it would be nice (although not necessary) to have
a simpler to understand, limited Proto, eg. just a Macro with parameter
substitution.
>>
>> A related question is if such a Macro node could coexist with Protos if
it would come to it, given their overlap. I think it probably could. [To
make it simple, one could disallow usage of Macros within proto
declarations and vice versa.] [[I think, usage of Macro instances within
Macro templates is currently not possible. Should it?]]
>
>
> Interesting possibilities, for sure.
>
> A number of macro options exist in different programming languages.
>
>         Wiktionary: macro
>         https://en.wiktionary.org/wiki/macro
>         (programming, computing) A comparatively human-friendly
abbreviation of complicated input to a computer program.
>         /The pre-processor expands any embedded macros into source code
before it is compiled./
>
>         https://en.wikipedia.org/wiki/Macro_(computer_science)
>
> Regarding source expansion:  since ProtoInstance/fieldValue
initializations can tickle Switch/Script activity, and since an existing
ProtoInstance can receive/send events like any other X3D node tree, they
have full parameter-driven expansion capabilities already.
>
> Similarly regarding expansion:  Inline scenes with IMPORT/EXPORT
similarly allow event passing to create or modify content at run time.
Sort of a simpler form of expansion/variation, providing similar expressive
power in a simpler way.
>
> Of course, "brute force" literal construction of scene graph subtrees,
using internal/external scripts, can also create whatever you want:
on-the-fly scene creation at run time.
>
> So yes it will be interesting if a Macro node fills an authoring niche in
this rich space.

I think it would fill the niche of scriptless, basic templating.

>
>> As a side note, in an html/DOM environment many scene creators would use
a templating engine:
>> https://www.sitepoint.com/overview-javascript-templating-engines/
>> But this requires some non-declarative programming and as such is
outside the scope of x3d.
>
>
> yes, using JavaScript-based code creation libraries for HTML and/or X3D
seems likely.

These engines require js coding from scene/html authors although there may
be one similar to the Macro node.

>
>>>     b. Usage examples are often helpful for illustrating goals at this
stage of design.
>>
>>
>> Since no internal computations are possible, usage would be limited.
There is still a class of useful templates: variations of color, dimensions
(eg., an arrow macro), perhaps timesensor/interpolator/route animation
macros, perhaps shaders with parameters, probably many others.
>
>
> Simple examples (even prior to any implementation effort) are helpful -
sort of like unit testing and test-driven development motivations, it is
tricky to properly implement something new if you can't define what success
looks like.

Universal Media Materials would be a basic example. As an enhancement a
Macro could have a 'shine' parameter which allows tweaking of the default
shininess of the material if provided.

>
>> [Currently, one could likely (ab-)use the Macro to also include a DOM
script node which would be affected by parameter substitution and which
then could set fields of x3d nodes in the instance with computed/generated
values upon execution during final parsing].
>
>
> Yes, close consideration of security considerations is important
throughout X3D.  Security is an area we have decided to be more explicit
about in the next specification.  Current collection of security issues and
resources can be found at
>
>         http://www.web3d.org/x3d/content/examples/X3dResources.
html#Security

While there well may be security implications, my afterthought was more
about potential flexibility with computability of parameter values using
DOM manipulation. But this would not be x3d compatible.

>
>>>     c. Previous efforts on NetworkSensor node, and the difficulties
encountered, may be worth considering:
>>>
>>>             http://www.web3d.org/x3d/content/examples/Basic/Networking/
<http://www.web3d.org/x3d/content/examples/Basic/Networking/>
>>>             http://www.web3d.org/x3d/content/examples/Basic/Networking/
NetworkSensorConnectionPrototypes.x3d <http://www.web3d.org/x3d/
content/examples/Basic/Networking/NetworkSensorConnectionPrototypes.x3d>
>>>             http://www.web3d.org/x3d/content/examples/Basic/Networking/
NetworkSensorConnectionPrototypes.html <http://www.web3d.org/x3d/
content/examples/Basic/Networking/NetworkSensorConnectionPrototypes.html>
>>>
>>>             http://www.web3d.org/x3d/content/examples/Basic/Networking/
NetworkSensorConnectionNodes.html <http://www.web3d.org/x3d/
content/examples/Basic/Networking/NetworkSensorConnectionNodes.html>
>
>
>> I think the Macro node would not be able define new fields if this is
the concern. Is it ?
>
>
> Depends on design... the signature lists /url/ plus MFString /params/
name=value pairs as well as SFELEMENT /parameter/ and MFElement
/parameters/.

Yeah, it looks like the idea would be
Macro
 parameters
  param name='myname' value='string'

which looks not unreasonable, to me.

>
> So a lot appears to be going on.  Actually for experimenting with design,
Macro implementation might even be possible as a prototype; no really.
Gaps and support would help clarify how it might differ.

Hmm, seems hard to do at first glance. It would be a good way to learn
about differences.

Andreas
>
> Onward we go, many interesting possibilities, again thanks.
>
> all the best, Don
> --
> Don Brutzman  Naval Postgraduate School, Code USW/Br
brutzman at nps.edu
> Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA
+1.831.656.2149
> X3D graphics, virtual worlds, navy robotics http://faculty.nps.edu/
brutzman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20160829/4daf4eaa/attachment-0001.html>