<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Andreas makes some good points, and I'm going to address some of them with net/coderextreme/X3DJSONLD.java (found on sourceforge) which perhaps I haven't introduced properly. X3JSONLD.java provides for loading JSON into Java DOM documents , similar to how X3DJSONLD.js provides for loading JSON into ECMAScript, node and JavaScript DOM documents.<div><br></div><div>Once the JSON is loaded into X3DJSONLD.java, it can be exported to a Java document object using loadJsonIntoDocument.  I agree that there's no common method for this between X3DJSONLD, X_ITE and X3DOM.  That because there wasn't a standard for JSON yet.  Once we have an X3D JSON standard, the various APIs should be normalized.</div><div><br></div><div>Here is a example version for Nashorn:</div><div>-----------------------------------------------------------------------------------------------------------------------</div><div>load('classpath:nashorn/node/X3Dautoclass.js');<br>var ConfigurationProperties = Packages.org.web3d.x3d.jsail.ConfigurationProperties;<br>ConfigurationProperties.showDefaultAttributes = false;<br>ConfigurationProperties.xsltEngine = ConfigurationProperties.XSLT_ENGINE_NATIVE_JAVA;<br>ConfigurationProperties.deleteIntermediateFiles = false;<br>ConfigurationProperties.setStripTrailingZeroes(true);<br><br>var X3DJSONLD = Java.type("net.coderextreme.X3DJSONLD")<br>var loader = new X3DJSONLD();<br>var File = Java.type("java.io.File")<br>var jsobj = loader.readJsonFile(new File("./examples/Nashorn.json"));<br>var document = loader.loadJsonIntoDocument(jsobj);<br>print(loader.serializeDOM(loader.getX3DVersion(jsobj), document));<br></div><div>--------------------------------------------------------------------------------------------------------</div><div>This nashorn version should be standalone, separate from X3DJSONLD (the app).</div><div><br></div><div>Webapp builds are creating binary now with WebASM, but WebASM is not DOM or JSON.  It seems like they are trying to bring C/C++ apps into the web. My best guess is that developers are working very hard to squash JavaScript, and later Java.  JavaScript is fighting back with glTF.  But C++/C has a long history with openGL, and I think that WebASM includes it, if not webGL.  I do not know why Java does not play well as a browser.  WebKit (or cousin) seems to be everywhere, even in Java (hint, there's a WebKit in Java we can target with X_ITE and X3DOM).</div><div><br></div><div>It would seem like C++, streams, and STL may be the future, if not python for webapps.</div><div><br></div><div>The good news is we have a way in JavaScript for loading JSON into the document object or browser--X3DJSONLD.js/JSONParser.js  It's lightweight, even with JSON validation (JSONParser.js relies on DOM for security).</div><div><br></div><div>But...</div><div><br></div><div>It's not typesafe.</div><div><br></div><div>There's solutions for that:</div><div><br></div><div><ol><li>Create a typesafe JavaScript library with X3DUOM and XSLT. This is under our control--but i won't do it.</li><li>Create a typesafe TypeScript library with JSweet.  This is NOT under our control.</li><li>Create a typesafe JavaScript library with Python.   This is under our control--I can try to do this.</li></ol><div>In any case, I do not recommend the second choice until we can decrease the size of the library download compared to other solutions like X_ITE.</div></div><div><br></div><div>In any case, it looks like the X3dToES5.xslt is being kept up to date without my assistance!</div><div><br></div><div>If you want me to create the X3D.js library, I will look at X3dToES5.xslt results, and attempt to modify the following to suit.  Please generate some X3dToES5.xslt examples, so I will know what target I am aiming for, similar to how there was tons of JSON before I wrote X3DJSONLD.js.  "Test early, test often"</div><div><br></div><div>x3d-code/<a href="http://www.web3d.org/x3d/stylesheets/java/src/python/pythonapi/packageGenerator.py" target="_blank">www.web3d.org/x3d/stylesheets/java/src/python/pythonapi/packageGenerator.py</a><br></div><div>(not currently used, was my research project for python class hierarchy).</div><div><br></div><div>It may not be perfect yet, but it fits my mindset.  XSLT does not.</div><div><br></div><div>I can set forth a design that an XSLT developer can follow after.</div><div><br></div><div>Will X3DUOM become our tool of choice for defining APIs, or will we later go with OpenAPI or Swagger or TTL?  What's the future?</div><div><br></div><div>Why isn't there a industry standard way of defining APIs separate from a particular language?  OH YEAH! It's called UML!  Why don't we use UML?</div><div><br></div><div>John</div><div><br></div><div><a href="https://img.picturequotes.com/2/121/120031/testing-leads-to-failure-and-failure-leads-to-understanding-quote-1.jpg">https://img.picturequotes.com/2/121/120031/testing-leads-to-failure-and-failure-leads-to-understanding-quote-1.jpg</a></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Mar 25, 2020 at 8:47 AM Andreas Plesch <<a href="mailto:andreasplesch@gmail.com" target="_blank">andreasplesch@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi John, Don,<br>
<br>
I am trying to follow the discussion somewhat but have quite limited<br>
availability now.<br>
<br>
Here are some considerations, unfortunately quite unconnected.<br>
<br>
Ecmascript best practices<br>
<br>
It is not clear that there are commonly accepted standards since the<br>
language is forgiving having evolved so much. But here are perhaps<br>
some guides. An often encountered viewpoint is that the language is<br>
not very OO oriented but rather functional in nature. So OO principles<br>
do not necessarily apply but could be used anyways. There are now<br>
classes in Ecmascript although my understanding is that they are<br>
largely considered syntactical sugar. Another principle is that since<br>
it is a largely interpreted language which relies on garbage<br>
collection, object reuse is favored over object creation and<br>
destruction. Three.js, for example, is very strict about this, and<br>
part of the reason why it is performing well. x3dom is not very strict<br>
about this on the other hand, and still does ok. As node.js is a<br>
target one needs to be careful to distinguish between DOM/browser<br>
features and language features. Node.js natively does not have DOM<br>
methods but a DOM and methods can be added with a library. Also, keep<br>
in mind that currently there is no X3D runtime for node.js.<br>
x3dom/x_ite cannot be run in node.js. So one, expensive, experiment<br>
would be to try to extract a node compatible runtime by separating the<br>
rendering and input controls out of these engines.<br>
<br>
Scene Authoring/Construction versus Scene Access<br>
<br>
Ecmascript differs from Python or Java in that it is the primary<br>
language for X3D scripts used internally in scenes, and externally to<br>
access scenes in running browsers. This is what the current SAI spec.<br>
defines, and what I understand to be Scene Access. This includes but<br>
is not limited to constructing new nodes and entire scenes<br>
programmatically. In addition to construction, SAI also allows for<br>
controling a browser, and modifying a running scene. In contrast,<br>
X3DJ/PSAIL is limited to constructing and authoring a scene which can<br>
eventually be serialized as xml or json, and be used to load into X3D<br>
browser. It seems perhaps prudent for now to parallel X3DJSAIL and<br>
just focus on scene authoring, and not be concerned about live scene<br>
control and modification.<br>
<br>
JSON<br>
<br>
Since the X3D JSON encoding now exists, a useful and specific question<br>
is if the Ecmascript JSON.parse() function<br>
(<a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/JSON/parse" rel="noreferrer" target="_blank">https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/JSON/parse</a>)<br>
should return a value which can be immediately used by the envisioned<br>
library given a JSON encoded string. Conversely, should the Ecmascript<br>
JSON.stringify() function generate directly X3D JSON encoding if given<br>
a library generated object ?<br>
<br>
-Andreas<br>
<br>
<br>
<br>
On Tue, Mar 24, 2020 at 9:20 AM Don Brutzman <<a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a>> wrote:<br>
><br>
> 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>
<br>
<br>
<br>
--<br>
Andreas Plesch<br>
Waltham, MA 02453<br>
</blockquote></div>