[x3d-public] [x3dom-users] XSLT and XML -> applications conversion volunteer position (training available through zoom or skype sessions)

John Carlson yottzumm at gmail.com
Wed May 6 23:35:57 PDT 2020


I haven't proofread this too well.

Note that I didn't use the term "JavaScript" in my email.  Instead, I am
focusing on standardized ECMAScript (node.js first, because that's low
hanging fruit with a java module similar to Nashorn's)

The node.js code I expect X3dToNodeJS.xslt to produce will be compatible
JNI-wise with X3DJSAIL, thus there already is a Node.js SAI just like there
is a X3DJSAIL SAI (Except for non-X3DUOM classes of course, which can be
added hopefully to the autoclass file--got a list I can process?).  Enjoy,
and debug by all means.   We've always created the X3DJSAIL-based versions
first.

I'm still chasing the similar JNI problems around I guess.

Following the same path we did with python, I know.  I saw the JNI problem
a mile away with Python, and started desperately creating an alternate
generated SAI, but I failed on XML generation. Now with ES6, I think I've
succeeded at XML generation--now we need to extensively test it.

The win on generating apps first is you get a ton of files to test against
while you are building your library.  So i took your advice, and created a
single example for ES6, and published it with a library so you can see how
they work together.  You can read my other emails and below for that.  I
only have one application, but that's okay right now, when we're still
implementing non-X3DUOM classes.

Do you recommend totally giving up on X3DJSAIL.*.jar for
ECMAScript,Python,C/C++/C#?  I was hoping to have a second implementation
for those languages in a small amount of time.  Let me talk about where my
current thinking is going.  The
X3DJSONLD/src/main/language/net/coderextreme/data/* are apps created by my
serializers.  The X3DJSONLD/src/main/language/net/x3djsonld/data/* are apps
created by stylesheets. I am working on a dual testing environment.

I'm working on ES6 SAI, skipping over ES5 SAI, not related to X3DJSONLD or
X3DJSAIL, just relying on X3DUOM.  See es6 folder under
www.web3d.org/x3d/stylesheets on sourceforge.  Once we give up on this
current JNI problem with getName, and possibly other JNI problems in
Node.js java module, we'll be progressing directly towards ES6 for Node.js
implementation.  I have a sample /app.mjs/ in the es6 folder which imagines
what a new ECMAScript SAI might be, which I've been inviting people to
comment on, provide feedback on, etc.  with *ZERO* FEEDBACK!, but it needs
to be resolved against existing X3D SAI (X_ITE).   The x3d.mjs is the X3D
module supporting the SAI.  There needs to be a Browser class added to it,
which I will now ask for volunteers to write--wait.  We don't need a new
ES6 SAI for X_ITE, indeed, it's kind of like what we did in the ES5 days
with AngularJS, etc.  We're doing what Angular (TypeScript) is now focused
on...classes, So we'll hopefully jump right into Angular, React, TypeScript
are doing, not something ancient. ES6 doesn't have interfaces, AFAICT, so
we'll need to do something with TypeScript for the X3D* interfaces.  I
believe your x3d.py may also be missing a Browser class, and thus it is NOT
SAI!  It's way off SAI, because it uses X3DOM, which does not have much of
an SAI implementation.

Note that Foo-Impl.java I believe is normally reserved for an *impl*ementation,
not an interface????

see this in X3DJSAIL: public interface BrowserFactoryImpl

So I am currently supporting the ECMAScript stylesheets, at least that's my
understanding.  If you want to take over the stylesheets: X3dToES5.xslt
(Nashorn--I'd leave it alone unless something crops up), X3dToNodeJS.xslt
(node.js, perhaps just a little tweaking/debugging to conform to X3DJSAIL),
and the to be created X3dToES6.xslt (generates one or more ES6 classes that
compose the "app" from XML), I will be willing to convert x3d.mjs to any
style of SAI you wish, using the x3d/stylesheets/es6/packageGenerator.py to
generate the source code.  With the various packageGenerator.py scripts
I've been writing (I have one for python too that's incomplete).  I'm
showing that there is a strawman alternative to XSLT, should one choose
that direction.

So I'm developing a parallel set of ECMAScript serializers to the
x3d/stylesheets ones targetted at X3DJSAIL.  I don't really want to
regenerate a whole new library X3DJSAIL for each programming language, but
perhaps that's best we can do.

If you've missed my previous mails, you will note that I have a *running*
ES6 app right now on mybinder jupyter notebook (well, just a rotatable
cube).  I'll probably be moving it to observablehq so I won't confuse the
ECMAScript for the python.

How do you propose to add the non-X3DUOM classes to something that's
parseable by me?  For node.js, I could probably add it to my autoclass file
that loads the Java classes.  But so far, I haven't required a Browser
class for what I'm doing.

Now that I have code to work with, I see that Browser has a address/port
parameter.   Now I understand EAI in terms of SAI, perhaps.

I did not see an address/port in any preexisting ECMAScript SAI examples.

John

On Wed, May 6, 2020 at 11:44 PM Don Brutzman <brutzman at nps.edu> wrote:

> John, it is hard to understand why we would focus on X3D -> JavaScript
> before we have stabilized on a JavaScript SAI.
>
> This is the exact same trajectory as we followed with Java.  Brilliantly
> shooting arrows isn't much help if we don't have a well-defined sustainable
> target.  Ready, aim, fire - in that order.
>
> On 5/6/2020 1:11 PM, John Carlson wrote:
> > I need help maintaining X3dToNodeJS.xslt (node.js X3DJSAIL apps--current
> issue), X3dToES5.xslt (nashorn, deprecated, X3DJSAIL apps, lower priority),
> and help creating X3dToES6.xslt (ECMAScript 6 SAI, non-X3DJSAIL apps).
> Files are stored here:
> https://sourceforge.net/p/x3d/code/HEAD/tree/www.web3d.org/x3d/stylesheets/ (you
> can create a separate project on github or sourceforge for now).
> >
> > The position will require experience or quick learning with XSLT, SAI,
> ECMAScript 5 and up.  Experience with X3DJSAIL/Java, Nashorn, Visual Studio
> Code, TypeScript, bash and Babel would be nice, but not required.
> >
> > Specifically, I need someone to search down the following problem and
> fix in X3dToNodeJS.xslt:
> >
> > $ node x3domflowers.js
> > x3domflowers execution self-validation test results: TypeError:
> meta.getName is
> > not a function
> >
> > I can't attach any JS files.  Here is the file, I think on my server.
> http://coderextreme.net/X3DJSONLD/src/main/node/net/x3djsonld/data/x3domflowers.js I
> know where the error is in the code, I just don't know how to fix it yet.
> >
> > Plus you will probably need an X3DJSONLD dev environment.
> >
> > This is an important position, and keeps our "first reference
> implementation" of the various conversions.  This parallels my conversions
> written in ECMAScript.
> >
> > Thanks,
> >
> > John
> >
> >
> >
> > _______________________________________________
> > X3dom-users mailing list
> > X3dom-users at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/x3dom-users
> >
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20200507/a7062182/attachment-0001.html>


More information about the x3d-public mailing list