[x3d-public] X3DJSAIL/X3DJSONLD. Next steps. JSON as a source encoding. Consider X3DJSSAIL?

[Don Brutzman]

On 1/15/2018 6:03 AM, John Carlson wrote:
> Don, I'd like to start adding JSON as a source file encoding to produce XML and Python as well as JavaScript in X3DJSAIL.   I know this is a big step for you, but it's a small step for me.   I believe I will need a -fromJSON command line argument and a -toPython argument added to Command line.  We will need someway to serialize JSON to XML through a Java port of X3DJSONLD,  to get to XML from JSON.   Unless you want to use X3DJSONLD's DOMserializer in JavaScript. 

John, thanks for this thoughtful planning.

Am thinking that we get the most benefit by having complementary capable codebases.  This ecosystem encourages programmers to use code in their native environment (JavaScript, Java, whatever).

Co-development also lets us test correctness, and lean on (i.e. reuse) each other's code wherever possible.  Am happy to continue exploring Nashorn jjs use of Java JavaScript and how to improve it.  Having powerful node.js types of capabilities natively available within Java is pretty amazing.

Am happy to work on -fromJSON invocation of your code drop from within X3DJSAIL.  Tell me how to invoke it from Java, and then adding the CommandLine switch is simple.

So your conversion ideas all fit together within the table showing what is needed most, X3DJSAIL support for various encodings and programming languages:

	X3DJSAIL Conversions Support
	http://www.web3d.org/specifications/java/X3dJavaSceneAuthoringInterface.html#Conversions

Am also happy to add a -toPython capability, if you indeed have some kind of draft X3D Python language binding.  The path to that is probably
a. Document the suggested syntax you've shared in some examples,
b. Get it runnable so that we can test correctness,
c. We write an X3dToPython.xslt stylesheet to allow testing of all other .x3d examples,
d. Showing X3DJSONLD support,
e. Then get export from within X3DJSAIL, either by invoking your code or writing a third serializer (it already can generate XML and [Classic]VRML encodings)

Interestingly we talked about these exact paths for success yesterday during the C++/C#/C SAI Binding implementation talks by Myeong Won Lee and Roy Walmsley during yesterdays Korea Chapter session.

	Web3D Korea Chapter, Mixed Augmented Reality (MAR) Meetings Seoul 2018
	http://www.web3d.org/event/web3d-korea-chapter-mixed-augmented-reality-mar-meetings-seoul-2018

> But then we would have dual -toX3d arguments, and your XML is prettier than mine.

X3DJSAIL support strives to meet X3D Canonicalization (C14N) upon serialization, and is pretty close.  So X3DJSAIL has that regardless of import path.

	X3D Canonicalization (C14N) .xml format
	http://www.web3d.org/documents/specifications/19776-3/V3.3/Part03/concepts.html#X3DCanonicalForm

We also have a Java application for that.

	X3D Canonicalizer
	https://svn.code.sf.net/p/x3d/code/www.web3d.org/x3d/tools/canonical/doc/x3dTools.htm

Anyway we can continue tweaking both of our XML outputs to meet X3D C14N requirements.  In addition to helpfulness for simple diff-ing, it is also a prerequisite for XML Security of digital signature and encryption.

(Also need to clean up X3DJSAIL's VRML serialization, the whitespace output is pretty ragged.)

> So perhaps a port of X3DJSONLD to Java is indicated.   Would this be easier to spread across the classes, or would we use DOM code and import the DOM into the concrete classes?   The latter may be simpler, as that's how X3DJSONLD is currently structured.   I'm thinking we should have DOM feeding the concrete classes for many things.

OK... but maybe we can think even more strategically for broader X3D impact in many directions...

Might we refactor X3DJSONLD as an X3D JavaScript Scene Access Interface Library (X3DJSSAIL)?

Even broader co-development might occur.  Seems like you have many/most of the challenging parts already accomplished. We then encourage MWL and Roy to think about how their library might similar grow towards becoming X3DCSAIL (or somesuch).  A future Python-native library might be X3DPSAIL, etc. etc.

Also discussed yesterday: a key design benefit is that we don't have to think about native rendering, and can let the various X3D players worry about that for us.  Instead these can be plain old object libraries that allow reading/creating/writing X3D models in various flavors.  Supports application integration, offline server-side processing, data-drive Big Data workflows, etc. etc.

More and more interesting possibilities are certainly emerging.

Have fun with X3D programming!  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