[x3d-public] JSweet translation of X3DJSAIL to JavaScript: need specific design goals first

Wed Apr 8 21:06:07 PDT 2020

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.

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.

Here is a example version for Nashorn:
-----------------------------------------------------------------------------------------------------------------------
load('classpath:nashorn/node/X3Dautoclass.js');
var ConfigurationProperties =
Packages.org.web3d.x3d.jsail.ConfigurationProperties;
ConfigurationProperties.showDefaultAttributes = false;
ConfigurationProperties.xsltEngine =
ConfigurationProperties.XSLT_ENGINE_NATIVE_JAVA;
ConfigurationProperties.deleteIntermediateFiles = false;
ConfigurationProperties.setStripTrailingZeroes(true);

var X3DJSONLD = Java.type("net.coderextreme.X3DJSONLD")
var loader = new X3DJSONLD();
var File = Java.type("java.io.File")
var jsobj = loader.readJsonFile(new File("./examples/Nashorn.json"));
var document = loader.loadJsonIntoDocument(jsobj);
print(loader.serializeDOM(loader.getX3DVersion(jsobj), document));
--------------------------------------------------------------------------------------------------------
This nashorn version should be standalone, separate from X3DJSONLD (the
app).

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

It would seem like C++, streams, and STL may be the future, if not python
for webapps.

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

But...

It's not typesafe.

There's solutions for that:

   1. Create a typesafe JavaScript library with X3DUOM and XSLT. This is
   under our control--but i won't do it.
   2. Create a typesafe TypeScript library with JSweet.  This is NOT under
   our control.
   3. Create a typesafe JavaScript library with Python.   This is under our
   control--I can try to do this.

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.

In any case, it looks like the X3dToES5.xslt is being kept up to date
without my assistance!

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"

x3d-code/
www.web3d.org/x3d/stylesheets/java/src/python/pythonapi/packageGenerator.py
(not currently used, was my research project for python class hierarchy).

It may not be perfect yet, but it fits my mindset.  XSLT does not.

I can set forth a design that an XSLT developer can follow after.

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?

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?

John

https://img.picturequotes.com/2/121/120031/testing-leads-to-failure-and-failure-leads-to-understanding-quote-1.jpg

On Wed, Mar 25, 2020 at 8:47 AM Andreas Plesch <andreasplesch at gmail.com>
wrote:

> Hi John, Don,
>
> I am trying to follow the discussion somewhat but have quite limited
> availability now.
>
> Here are some considerations, unfortunately quite unconnected.
>
> Ecmascript best practices
>
> It is not clear that there are commonly accepted standards since the
> language is forgiving having evolved so much. But here are perhaps
> some guides. An often encountered viewpoint is that the language is
> not very OO oriented but rather functional in nature. So OO principles
> do not necessarily apply but could be used anyways. There are now
> classes in Ecmascript although my understanding is that they are
> largely considered syntactical sugar. Another principle is that since
> it is a largely interpreted language which relies on garbage
> collection, object reuse is favored over object creation and
> destruction. Three.js, for example, is very strict about this, and
> part of the reason why it is performing well. x3dom is not very strict
> about this on the other hand, and still does ok. As node.js is a
> target one needs to be careful to distinguish between DOM/browser
> features and language features. Node.js natively does not have DOM
> methods but a DOM and methods can be added with a library. Also, keep
> in mind that currently there is no X3D runtime for node.js.
> x3dom/x_ite cannot be run in node.js. So one, expensive, experiment
> would be to try to extract a node compatible runtime by separating the
> rendering and input controls out of these engines.
>
> Scene Authoring/Construction versus Scene Access
>
> Ecmascript differs from Python or Java in that it is the primary
> language for X3D scripts used internally in scenes, and externally to
> access scenes in running browsers. This is what the current SAI spec.
> defines, and what I understand to be Scene Access. This includes but
> is not limited to constructing new nodes and entire scenes
> programmatically. In addition to construction, SAI also allows for
> controling a browser, and modifying a running scene. In contrast,
> X3DJ/PSAIL is limited to constructing and authoring a scene which can
> eventually be serialized as xml or json, and be used to load into X3D
> browser. It seems perhaps prudent for now to parallel X3DJSAIL and
> just focus on scene authoring, and not be concerned about live scene
> control and modification.
>
> JSON
>
> Since the X3D JSON encoding now exists, a useful and specific question
> is if the Ecmascript JSON.parse() function
> (
> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/JSON/parse
> )
> should return a value which can be immediately used by the envisioned
> library given a JSON encoded string. Conversely, should the Ecmascript
> JSON.stringify() function generate directly X3D JSON encoding if given
> a library generated object ?
>
> -Andreas
>
>
>
> On Tue, Mar 24, 2020 at 9:20 AM Don Brutzman <brutzman at nps.edu> wrote:
> >
> > 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.
> >
> > But that is distracting and confusing way to solve a problem and leads
> to "fire, ready, aim!" implementation pathologies.
> >
> > A further risk might be that JSweet might carry through unnecessary Java
> programming idioms, but presumably they have sorted through that well
> already.
> >
> > 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.
> >
> > 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.
> >
> > Authoring use-case environments are
> > 1. Script inside X3D scene graph,
> > 2. Script in outer HTML5 web page,
> > 3. Standalone programmatic use in node.js
> >
> > Now get specific.  Recommend listing pseudocode and design patterns for
> JavaScript Transform class and JavaScript X3D types, comparing:
> >
> > a. X3D ECMAScript specification,
> > b. X3D Script code fields (class variables) and methods,
> > c. good general-practice OO design pattern(s) in common use,
> > d. current X3D JSON approach, is it OK or improvable further?
> > e. compare/contrast Transform approach with X3DJSONLD,
> > f. compare/contrast Transform approach with X_ITE,
> > g. compare/contrast Transform approach with X3DOM,
> > h. compare/contrast Transform approach with three.js,
> > j. compare/contrast Transform approach with any other javascript
> libraries of interest,
> > i. compatibility of Transform approach with Angular, React, jquery,
> other common JavaScript frameworks for HTML.
> >
> > We did this kind of comparison for X3D JSON design and it helped make a
> confusing understandable, eventually leading to good design decisions.
> >
> > If interested parties prepare this kind of comparison, and understand
> "what" we want that has general appeal, then progress refinement will be
> straightforward.
> >
> > Many people use JavaScript these days, especially with node.js - check
> whether they like the result.
> >
> > When you have solid patterns then we convert 4,000 X3D example scenes
> (from .x3d -> .js) to match, providing unit tests.  Lather, rinse, repeat...
> >
> > Hope this outline helps.  Good luck out there!  8)
> >
> > 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
>
>
>
> --
> Andreas Plesch
> Waltham, MA 02453
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20200408/8b8c1696/attachment.html>