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

Sun Aug 28 16:42:20 PDT 2016

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.

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.

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

	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.

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.

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

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

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

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

>>     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/.

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.

> some input,
>
> 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