[x3d-public] C# opportunities, X3DJSONLD/JS or XSLT

Thu Mar 24 20:24:06 PDT 2022

Hi John, 
(to me) specifying the json transcoding of x3d xml and Classic is not directly related to specifying the C/C++/C# bindings. 

To prove json as an alternate encoding , a file with json encoding needs to result in equivalent user code structure and content so an x3d browser could run the scene in the same way regardless of which xml, classic, or json is provided as user code input. I don’t think json needs to do all that, but only serve as a well defined way to import file-based x3d field data for a certain node, but, if we want to document a complete alternate dedicated encoding such as an x3d json then we need to provide specification keystrokes, schema and converter, and a browser or two that will accept a scene encoded in spec json. At this time in order to proceed on that it seems like time to pay attention to what the specification for x3d json would be. 

The C/C++/C# programming languages can work in x3d when they can provide the required x3d SAI browser.scene.executionContext.node.field interface bindings for use in the x3d script node. So, these bindings must demonstrate the script working as described in the SAI abstract and like in the ecmascript and java SAI specifications. Again, this work is now in some level of draft stage and completely different than showing x3d json. 

As always, quite a bit of fun available with x3d
Joe

From: John Carlson
Sent: Thursday, March 24, 2022 2:02 PM
To: Joseph D Williams
Cc: Brutzman, Donald (Don) (CIV); X3D Graphics public mailing list
Subject: Re: [x3d-public] C# opportunities, X3DJSONLD/JS or XSLT

We have examples, but I’m not sure if validate() or XML or JSON or VRML export is available for C/C++/C# bindings, which are pretty essential for testing examples.

On Thu, Mar 24, 2022 at 2:36 PM Joseph D Williams <joedwil at earthlink.net> wrote:

a. first need a codebase to run models and to test them,
seems like we have many examples of successful conversion.
All Best, 
Joe

On Tue, Mar 22, 2022 at 3:42 PM Joseph D Williams <joedwil at earthlink.net> wrote:

• then we can convert X3D models

OK, seems now I see (at least) two big ‘convert’ works. 
One is simply to show that x3d canonical syntax can be represented in various alternative encodings, one being json, and that the encoding can then have a schema in that encoding, and that the encoding can be returned to canonical x3d syntax for validation. 
Two is to validate new scripting languages and how they can be used in an x3d script node. 

Funny enough, I think Two is the most simple, just show working code to show functionality of the SAI for important browser and scene context using a scripting language other than ECMAScript or java, the same way that ECMAScript and java works in an execution context. C and Cwhatever have been and are important. Especially when developing complex prototypes when you needed max simulation power for graphics and math algorithms. Much of this need is now exposed in the html browser by the gl, and along with the incredible speedups of java and ECMAScript running in the html browser making x3d in html almost as many possibilities as running x3d ‘standalone’ browser directly in our www. However, when doing complicated stuff, like stuff that performs complex realistic behaviors, authors may still need to go deeper and faster into the C. 

The One has plenty of examples, simply present a systematic determination of best practice conversion of an existing, known to be validated canonical xml encoding into the alternate syntax, for example json, then back. That is what was done for the xmlization of vrml. In a way, this is also the thing for gltf2 also. However, the gltf2 has its own schema for each of its features, and may not apply directly or completely to any x3d nodes, so are distinct from any json schema that may be derived directly from xml schema (if possible?). 

However, my overall feeling is that Yes, x3d should formulate a specific standard for importing data for any field of any node using a json form where the x3d user code for the field of the node names the json file and the field to be imported for that field. The author should have control of those names and one json file may contain named data for more than one field of an x3d node, and/or contain named data fields used in more than one x3d node.  
This is general purpose json import/export for x3d not necessarily related to gltf2. The gltf forms serve special cases where an independent standards body has decided to define some general-purpose data items commonly used in industrial graphics operations using json form. Of course x3d finds these gltf mostly very useful because, of course, they carry data used in everyday x3d. 
The general case of json import/export where the author decides how to actually obtain/deliver authortime/runtime json data structures from/to a json file for some purpose whenever from wherever adds json power (whatever that may turn out to be) in x3d. 

Thanks, 
Joe

From: Brutzman, Donald (Don) (CIV)
Sent: Monday, March 21, 2022 1:56 AM
To: Joseph D Williams; John Carlson; X3D Graphics public mailing list
Cc: Brutzman, Donald (Don) (CIV)
Subject: RE: [x3d-public] C# opportunities, X3DJSONLD/JS or XSLT

Yes that is the spirit, one conversion at a time, one step at a time.

As shown and reported repeatedly with JSON Java Python Turtle etc., reinforcing John’s p:

f. first need a codebase to run models and to test them,
g. this should match a draft specification,
h. then we can write a converter,
i. then we can convert X3D models and test them in new language,
j. then we get each one working and matching/improving the draft language specification for X3D

Once this process is established satisfactorily for a few X3D models, then the conversion-validation tasks can be added to our build scripts for 3900+ X3D Examples models.

Each of those model conversions occurs one at a time.  Each of the successes or failures are reviewed one at a time.  Each bug that occurs is corrected and improved one at a time.  Rinse lather repeat.

Library authors and users then have an extremely high level of confidence that the code works, and a thorough build log reveals any bugs that still need fixing.

Proven process for success.  Have fun with X3D!  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 https:// faculty.nps.edu/brutzman

From: x3d-public <x3d-public-bounces at web3d.org> On Behalf Of Joseph D Williams
Sent: Sunday, March 20, 2022 5:16 PM
To: John Carlson <yottzumm at gmail.com>; X3D Graphics public mailing list <x3d-public at web3d.org>
Subject: Re: [x3d-public] C# opportunities, X3DJSONLD/JS or XSLT

• The goal is to convert 3000+ xml documents to c#.

Please show me the first one you wish to convert. 

Thanks,
Joe

From: John Carlson
Sent: Sunday, March 20, 2022 12:52 PM
To: X3D Graphics public mailing list
Subject: [x3d-public] C# opportunities, X3DJSONLD/JS or XSLT

There is an opportunity for a C#/JavaScript/XSLT programmer to contribute to X3D.

We would like to serialize SAI C# code from DOM documents, using JavaScript.  There are examples to follow, including Java, C and C++ serializers (perhaps c/c++ are incomplete)

Alternatively, we could write XSLT instead of JavaScript.  We have many examples to follow, including Python.

Alternatively, we could write C# instead of XSLT or JavaScript.

The goal is to convert 3000+ xml documents to c#.

John

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20220324/e2d49dd7/attachment.html>