[x3d-public] deprecating portions of X3DJSONLD (JavaScript output)

[John Carlson]

This appears to be the bridge i saw on github.  I am not sure if it would
work.

https://github.com/LivePersonInc/kafka-java-bridge

Probably the best approaches that i know of is GraalVM —nashorn, or
preferably JavaScript SAI (X3DOM, X_ITE or freewrl — others?)
——

I do not see a future with a common API.  Each language/browser will
implement the abstract SAI and concrete SAIs.  That means the SAI program
will likely be tied to a browser or library, and possibly authoring tools.
Which pretty much limits portable X3D programs to simple logic and
declarative logic.

What is the purpose of SAI?  It seems like it’s best used as a network
protocol or EAI. @Chris

Common APIs means tooling for different bindings can be reused.   I believe
that has been my goal with X3DJSONLD, it didn’t work out.  AFAIK, there’s
no AST or IR that we can use, we’re stuck converting between encodings.
I’m poking a bit here!  Certainly I’m converting from JSON to XML/DOM in
X3DJSONLD because I believe XML/DOM is a superior, well supported
AST/IR/encoding.  I do hope that XML/DOM versions of glTF start emerging!

If someone wants to use X3DJSONLD.js for this, speak up!

Hmm!

John

On Fri, Apr 21, 2023 at 11:57 AM John Carlson <yottzumm at gmail.com> wrote:

> I am planning on deprecating portions of X3DJSONLD.
>
> At a minimum:
>
> JSON/XML/DOM to JavaScript conversion (Reason: no updates to the Java NPM
> package for ES6  (?), missing JSON file)
>
> If someone wants to work on this, perhaps using another javascript to java
> bridge (kafka? nashorn?), let me know!  It may be as simple as fixing the
> java/npm installation.
>
> I don't think this is working for anyone at this time.
>
> Further ES6 SAI enhancements will appear in es6x3d (x3d.js) and
> ECMAScriptSerializer.mjs (no Java required) and/or other ECMAScript SAI
> implementations.   My ECMA stuff has not been verified.  Work on this is
> not guaranteed.
>
> X3dToNodeJS.xslt and X3dToES5.xslt are available elsewhere, skipping
> JSON.  These require X3Dautoclass.*js, I believe, from the X3DJSONLD
> distribution, and therefore, X3DJSAIL (not desired).  It may be best to
> save off these autoclass files.  There are also python programs which
> generate these files in X3DJSONLD.  I will be maintaining, but not testing
> the autoclass files into the future as X3D schemas change. These activities
> could be taken over from the sourceforge/schema group, but really, work
> should focus on ECMAScript SAI.
>
> Ideally, we'd get rid of the X3DJSAIL dependency for my JavaScript/ES6
> code entirely!
>
> This is an overall move away of X3DJSONLD supporting X3DJSAIL for other
> languages besides Java (which was suggested by Don many years ago--haven't
> quite got there yet).  Support for Java/X3DJSAIL will continue in X3DJSONLD
> for the near future.   Also, we plan on slowly developing x3d.py/X3DPSAIL
> programs for accepting JSON (see x3djsonld.py).
>
> Files using X3DJSAIL  which may be affected, not exhaustive,
> X3DJSONLD/src/main/...
>
> node/net/x3djsonld/data/X3Dautoclass.js
> node/X3Dautoclass.mjs
> python/autoclass.py
> python/net/coderextreme/data/x3dpsail.py (not maintained, see x3d.py)
> python/nodeclasses.py
> python/x3dpsail.py (not maintained, see x3d.py)
> shell/classpath
> shell/classpath.bat
> shell/stylesheet.sh
> shell/tsc.sh
>
> Note: I am not aware of the ECMAScript version for Nashorn or Kafka.
>
> John
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20230421/41a6e8ae/attachment.html>