<div dir="ltr"><p dir="ltr">I will intersperse short responses below.</p>
<p dir="ltr">On Aug 28, 2016 7:42 PM, "Don Brutzman" <<a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a>> wrote:<br>
><br>
> Thanks for the dialog Andreas.<br>
><br>
> On 8/28/2016 2:42 PM, Andreas Plesch wrote:<br>
>><br>
>> Hi Don,<br>
>><br>
>> to me, the idea here is to be very pragmatic in order to make some progress with html integration.<br>
>><br>
>>     Date: Sun, 28 Aug 2016 11:57:37 -0700<br>
>>     From: Don Brutzman <<a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a> <mailto:<a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a>>><br>
>>     To: Leonard Daly <<a href="mailto:web3d@realism.com" target="_blank">web3d@realism.com</a> <mailto:<a href="mailto:web3d@realism.com" target="_blank">web3d@realism.com</a>>><br>
>>     Cc: X3Dom Users <<a href="mailto:x3dom-users@lists.sourceforge.net" target="_blank">x3dom-users@lists.<wbr>sourceforge.net</a> <mailto:<a href="mailto:x3dom-users@lists.sourceforge.net" target="_blank">x3dom-users@lists.<wbr>sourceforge.net</a>>>, X3D Public<br>
>>             <<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a> <mailto:<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a>>><br>
>>     Subject: Re: [x3d-public] Nodes for V4<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>
>><br>
>><br>
>> I agree, the Macro node would offer nothing that is not already available with Protos.<br>
><br>
><br>
> Quite possibly, but i wasn't prejudging - simply wondering what was different.  Just trying to understand the goals so that innovation can add value.<br>
><br>
> 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.</p>
<p dir="ltr">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.</p>
<p dir="ltr">><br>
> 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.</p>
<p dir="ltr">To me, the most useful aspect is its simplicity.</p>
<p dir="ltr">><br>
>> The issue is, however, that in the foreseeable future Protos are not actually available with x3dom.<br>
><br>
><br>
> Actually I think that prototype support for X3DOM is much closer than ever before.<br>
><br>
> 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:</p>
<p dir="ltr">Yes, the goal would need to be to have expansion by simply adding a js expander to the web page with the scene.</p>
<p dir="ltr">>         thread: [x3d-public] Prototype Expander, Question on MFNode and creating -material object in JSON. Issue for JSON schema<br>
>         <a href="http://web3d.org/pipermail/x3d-public_web3d.org/2016-July/004960.html" target="_blank">http://web3d.org/pipermail/<wbr>x3d-public_web3d.org/2016-<wbr>July/004960.html</a><br>
><br>
>         Prototype Expander design outline<br>
>         <a href="http://web3d.org/pipermail/x3d-public_web3d.org/2016-July/004982.html" target="_blank">http://web3d.org/pipermail/<wbr>x3d-public_web3d.org/2016-<wbr>July/004982.html</a><br>
><br>
>         update following discussion telcon<br>
>         <a href="http://web3d.org/pipermail/x3d-public_web3d.org/2016-July/005017.html" target="_blank">http://web3d.org/pipermail/<wbr>x3d-public_web3d.org/2016-<wbr>July/005017.html</a><br>
><br>
>         example result to check if design pattern works<br>
>         <a href="http://x3dgraphics.com/examples/X3dForWebAuthors/Chapter14-Prototypes/#MaterialModulatorPrototypeExpanded" target="_blank">http://x3dgraphics.com/<wbr>examples/X3dForWebAuthors/<wbr>Chapter14-Prototypes/#<wbr>MaterialModulatorPrototypeExpa<wbr>nded</a><br>
><br>
>         <a href="http://x3dgraphics.com/examples/X3dForWebAuthors/Chapter14-Prototypes/MaterialModulatorPrototypeExpanded.x3d" target="_blank">http://x3dgraphics.com/<wbr>examples/X3dForWebAuthors/<wbr>Chapter14-Prototypes/<wbr>MaterialModulatorPrototypeExpa<wbr>nded.x3d</a><br>
>         <a href="http://x3dgraphics.com/examples/X3dForWebAuthors/Chapter14-Prototypes/MaterialModulatorPrototypeExpanded.html" target="_blank">http://x3dgraphics.com/<wbr>examples/X3dForWebAuthors/<wbr>Chapter14-Prototypes/<wbr>MaterialModulatorPrototypeExpa<wbr>nded.html</a><br>
><br>
> 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<br>
><br>
>         <a href="http://x3dgraphics.com/examples/X3dForWebAuthors/Chapter14-Prototypes/MaterialModulator.x3d" target="_blank">http://x3dgraphics.com/<wbr>examples/X3dForWebAuthors/<wbr>Chapter14-Prototypes/<wbr>MaterialModulator.x3d</a><br>
>         <a href="http://x3dgraphics.com/examples/X3dForWebAuthors/Chapter14-Prototypes/MaterialModulator.html" target="_blank">http://x3dgraphics.com/<wbr>examples/X3dForWebAuthors/<wbr>Chapter14-Prototypes/<wbr>MaterialModulator.html</a><br>
><br>
> 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.<br>
><br>
> 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.</p>
<p dir="ltr"><a href="https://developer.mozilla.org/en-US/docs/Web/API/XSLTProcessor" target="_blank">https://developer.mozilla.org/<wbr>en-US/docs/Web/API/<wbr>XSLTProcessor</a></p>
<p dir="ltr">With such a XSLT, it may be possible to have the browser do the expansion. However, this only works with xhtml.</p>
<p dir="ltr">><br>
> 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.<br>
><br>
> 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.<br>
><br>
> 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.</p>
<p dir="ltr">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.</p>
<p dir="ltr">><br>
>> To me it makes sense to give a node with a more narrow and simpler functionality than Protos a distinct name and distinct semantics.<br>
><br>
><br>
> Could well be.  It will be good to get some clear examples for further consideration.<br>
><br>
>> 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.<br>
>><br>
>> 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?]]<br>
><br>
><br>
> Interesting possibilities, for sure.<br>
><br>
> A number of macro options exist in different programming languages.<br>
><br>
>         Wiktionary: macro<br>
>         <a href="https://en.wiktionary.org/wiki/macro" target="_blank">https://en.wiktionary.org/<wbr>wiki/macro</a><br>
>         (programming, computing) A comparatively human-friendly abbreviation of complicated input to a computer program.<br>
>         /The pre-processor expands any embedded macros into source code before it is compiled./<br>
><br>
>         <a href="https://en.wikipedia.org/wiki/Macro_(computer_science)" target="_blank">https://en.wikipedia.org/wiki/<wbr>Macro_(computer_science)</a><br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> So yes it will be interesting if a Macro node fills an authoring niche in this rich space.</p>
<p dir="ltr">I think it would fill the niche of scriptless, basic templating.</p>
<p dir="ltr">><br>
>> As a side note, in an html/DOM environment many scene creators would use a templating engine:<br>
>> <a href="https://www.sitepoint.com/overview-javascript-templating-engines/" target="_blank">https://www.sitepoint.com/<wbr>overview-javascript-<wbr>templating-engines/</a><br>
>> But this requires some non-declarative programming and as such is outside the scope of x3d.<br>
><br>
><br>
> yes, using JavaScript-based code creation libraries for HTML and/or X3D seems likely.</p>
<p dir="ltr">These engines require js coding from scene/html authors although there may be one similar to the Macro node.</p>
<p dir="ltr">><br>
>>>     b. Usage examples are often helpful for illustrating goals at this stage of design.<br>
>><br>
>><br>
>> 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.<br>
><br>
><br>
> 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.</p>
<p dir="ltr">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.</p>
<p dir="ltr">><br>
>> [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].<br>
><br>
><br>
> 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<br>
><br>
>         <a href="http://www.web3d.org/x3d/content/examples/X3dResources.html#Security" target="_blank">http://www.web3d.org/x3d/<wbr>content/examples/X3dResources.<wbr>html#Security</a></p>
<p dir="ltr">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.</p>
<p dir="ltr">><br>
>>>     c. Previous efforts on NetworkSensor node, and the difficulties encountered, may be worth considering:<br>
>>><br>
>>>             <a href="http://www.web3d.org/x3d/content/examples/Basic/Networking/" target="_blank">http://www.web3d.org/x3d/<wbr>content/examples/Basic/<wbr>Networking/</a> <<a href="http://www.web3d.org/x3d/content/examples/Basic/Networking/" target="_blank">http://www.web3d.org/x3d/<wbr>content/examples/Basic/<wbr>Networking/</a>><br>
>>>             <a href="http://www.web3d.org/x3d/content/examples/Basic/Networking/NetworkSensorConnectionPrototypes.x3d" target="_blank">http://www.web3d.org/x3d/<wbr>content/examples/Basic/<wbr>Networking/<wbr>NetworkSensorConnectionPrototy<wbr>pes.x3d</a> <<a href="http://www.web3d.org/x3d/content/examples/Basic/Networking/NetworkSensorConnectionPrototypes.x3d" target="_blank">http://www.web3d.org/x3d/<wbr>content/examples/Basic/<wbr>Networking/<wbr>NetworkSensorConnectionPrototy<wbr>pes.x3d</a>><br>
>>>             <a href="http://www.web3d.org/x3d/content/examples/Basic/Networking/NetworkSensorConnectionPrototypes.html" target="_blank">http://www.web3d.org/x3d/<wbr>content/examples/Basic/<wbr>Networking/<wbr>NetworkSensorConnectionPrototy<wbr>pes.html</a> <<a href="http://www.web3d.org/x3d/content/examples/Basic/Networking/NetworkSensorConnectionPrototypes.html" target="_blank">http://www.web3d.org/x3d/<wbr>content/examples/Basic/<wbr>Networking/<wbr>NetworkSensorConnectionPrototy<wbr>pes.html</a>><br>
>>><br>
>>>             <a href="http://www.web3d.org/x3d/content/examples/Basic/Networking/NetworkSensorConnectionNodes.html" target="_blank">http://www.web3d.org/x3d/<wbr>content/examples/Basic/<wbr>Networking/<wbr>NetworkSensorConnectionNodes.<wbr>html</a> <<a href="http://www.web3d.org/x3d/content/examples/Basic/Networking/NetworkSensorConnectionNodes.html" target="_blank">http://www.web3d.org/x3d/<wbr>content/examples/Basic/<wbr>Networking/<wbr>NetworkSensorConnectionNodes.<wbr>html</a>><br>
><br>
><br>
>> I think the Macro node would not be able define new fields if this is the concern. Is it ?<br>
><br>
><br>
> Depends on design... the signature lists /url/ plus MFString /params/ name=value pairs as well as SFELEMENT /parameter/ and MFElement /parameters/.</p>
<p dir="ltr">Yeah, it looks like the idea would be<br>
Macro<br> parameters<br>
  param name='myname' value='string'</p>
<p dir="ltr">which looks not unreasonable, to me.</p>
<p dir="ltr">><br>
> 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.</p>
<p dir="ltr">Hmm, seems hard to do at first glance. It would be a good way to learn about differences.</p><p dir="ltr">
Andreas <br>><br>
> Onward we go, many interesting possibilities, again thanks.<br>
><br>
> all the best, Don<br>
> -- <br>
> Don Brutzman  Naval Postgraduate School, Code USW/Br       <a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a><br>
> Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA   <a href="tel:%2B1.831.656.2149" value="+18316562149" target="_blank">+1.831.656.2149</a><br>
> X3D graphics, virtual worlds, navy robotics <a href="http://faculty.nps.edu/brutzman" target="_blank">http://faculty.nps.edu/<wbr>brutzman</a><br>
</p>
</div>