<div><div dir="auto">It seems like you have issues with the “generate first” approach.   Might I suggest this how generative and generic programming proceeds?   It seems like you want to do a “test driven” or “test first” approach.   Might I suggest the “automated testing” approach, combined with the “continuous integration” approach?   That is, we generate our tests instead of writing them.   If you didn’t notice, I am following your pattern, except I use JavaScript and Python instead of XSLT.</div></div><div dir="auto"><br></div><div dir="auto">It seems like you want refined examples to choose from?</div><div dir="auto"><br></div><div dir="auto">That was nearly my first approach, except I was doing very short agile sprints, thus the examples were incomplete.</div><div dir="auto"><br></div><div dir="auto">Should we set aside some time for longer agile sprints?</div><div dir="auto"><br></div><div dir="auto">I suggest we start pursuing the new SAI by looking at the patterns in X3D resources examples? We should start with this to ensure backwards compatibility.  I suggest one change.  Make the scripts run under node.js instead of an X3D browser.</div><div dir="auto"><br></div><div dir="auto">I do have some experience writing cross browser scripts.</div><div dir="auto"><br></div><div dir="auto">The reason I choose the generative approach is to try to do DRY.  I would appreciate discussing how to do DRY with both your and my framework.   I do a lot of copy and paste in my framework and I’d like to reduce that.</div><div dir="auto"><br></div><div dir="auto">If you think that procedural content is not the way to go, look at some talks by “No Man’s Sky” authors.</div><div dir="auto"><br></div><div dir="auto">I’ll include the link on another post.</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">On Tue, Mar 24, 2020 at 8:20 AM Don Brutzman <<a href="mailto:brutzman@nps.edu">brutzman@nps.edu</a>> wrote:</div><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">John, certainly we need to pay attention to "how" a library conversion is performed.  JSweet is promising, and we have a number of conversion approached demonstrated already.<br>
<br>
But that is distracting and confusing way to solve a problem and leads to "fire, ready, aim!" implementation pathologies.<br>
<br>
A further risk might be that JSweet might carry through unnecessary Java programming idioms, but presumably they have sorted through that well already.<br>
<br>
First things first, please.  Let's begin with defining design goals.  That's how we accomplished creating Java and Python programming-language bindings for X3D.<br>
<br>
What we really need to understand is "what" a sharable X3D JavaScript library looks like, and how JavaScript programmers might then use it to author interactive X3D models.<br>
<br>
Authoring use-case environments are<br>
1. Script inside X3D scene graph,<br>
2. Script in outer HTML5 web page,<br>
3. Standalone programmatic use in node.js<br>
<br>
Now get specific.  Recommend listing pseudocode and design patterns for JavaScript Transform class and JavaScript X3D types, comparing:<br>
<br>
a. X3D ECMAScript specification,<br>
b. X3D Script code fields (class variables) and methods,<br>
c. good general-practice OO design pattern(s) in common use,<br>
d. current X3D JSON approach, is it OK or improvable further?<br>
e. compare/contrast Transform approach with X3DJSONLD,<br>
f. compare/contrast Transform approach with X_ITE,<br>
g. compare/contrast Transform approach with X3DOM,<br>
h. compare/contrast Transform approach with three.js,<br>
j. compare/contrast Transform approach with any other javascript libraries of interest,<br>
i. compatibility of Transform approach with Angular, React, jquery, other common JavaScript frameworks for HTML.<br>
<br>
We did this kind of comparison for X3D JSON design and it helped make a confusing understandable, eventually leading to good design decisions.<br>
<br>
If interested parties prepare this kind of comparison, and understand "what" we want that has general appeal, then progress refinement will be straightforward.<br>
<br>
Many people use JavaScript these days, especially with node.js - check whether they like the result.<br>
<br>
When you have solid patterns then we convert 4,000 X3D example scenes (from .x3d -> .js) to match, providing unit tests.  Lather, rinse, repeat...<br>
<br>
Hope this outline helps.  Good luck out there!  8)<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   +1.831.656.2149<br>
X3D graphics, virtual worlds, navy robotics <a href="http://faculty.nps.edu/brutzman" rel="noreferrer" target="_blank">http://faculty.nps.edu/brutzman</a><br>
</blockquote></div></div>