[x3d-public] [x3d] Proposal for X3D JSON encoding. Array of arrays foranyarray

[John Carlson]

Leonard, I will try to answer all of your questions.

1)  In order, as opposed to pre-order or post-order traversal of a tree.  This assumes you have a left and right side of the tree, and nodes are visited going around the left to right side of the tree, visiting the nodes when the path reaches the bottom part of a node.  It’s not done when constructing the JSON (yet), because I traverse the arrays with a for loop, constructing a new object, like:
If (old object is an array) 
	New object is an *new* array
Else
	New object is an *new* object
For (key in old object) {
	New object [ key ] = processing(old object [ key ])

Now there’s often a lot of processing for old object [ key ] before it becomes a new object [ key ] for many of the types of node I handle I handle in the prototype expander  some of those produce arrays currently.  So if I’m in the middle of processing an array and I get an  array out of processing, what do I do?  For objects, this is not an issue.  However, for arrays, I cannot just stick an array into an array per the standard. So what do I do?  I can keep track of another index, say array element, 
	For (arrayelement in “processing (old object [ key ]”) 
		New object [ key + array element ] = “processing(old object [key])” [ array element ]

Where quotes indicate a variable, not a function call.  Then I would have to keep track of another key2 for the next array I processed, since, array element will be reset to 0.

This ends up being really ugly code and does not lead to understand what is really happening.  Which the first set of code describes perfectly.  I also may have to handle the case where processing returns an empty object.  The code is so ugly, I would prefer to clean it up by putting it in in an unrelated script which processes all nested arrays into flat arrays (we may want to provide this anyway for people to comply with current standard).  Let’s call this new code FLATTENER.

I agree that FLATTENER is likely the best solution for this, and it can notify the user if there are unflatttened arrays if desired.  However, I’m lazy, and I’m always looking for a better, quicker solution.  Got one?  I think FLATTENER should be done AFTER the prototype expander. But before a loader or schema check.

2) Yes, Prototype Expander is the driving request.
3) The Prototype Expander handles the JSON encoding an the code is open source and found in this repository: https://github.com/coderextreme/X3DJSONLD/blob/master/PrototypeExpander.js  It takes Protos and extern Protos and makes non-proto code by duplicating prototobody code for each protoinstance.  This code has never been released under a different license, and is my original code—be warned that other code in that repository may have different licenses, and is a collection of code from the X3D Resource Example sites for the most part.  I can help nail down which code is mine and which is contributed (the JS is mine, the JSON and X3D may be others).  The code is written JavaScript, and is still in alpha testing.  You are welcome to report issues or nail down bugs with my help.  It can run standalone (see PPP.js) or in a browser/server fashion (see loaderJQuery.js/PrototypeExpander.js&app.js).  There is standalone JSON to XML converter called json2x3d.js and which is reliant on X3DJSONLD.js script.
3b) I have been working on integrating Inlines into the X3D JSON Loader, so I currently have two inline based functions which could be used either to incorporate new inlines in loaderJQuery.js, or probably arbitrary JSON code.  I do not currently handle inline XML.  We would have to decide where to place the FLATTENER code, but soon after the proto expander would be good.
4) You would have to run the code through the protoexpander to load protos on the fly.  I don’t currently do that, but state variables could be kept around for future use (likely recommended, I need to make that change).  What I am worried about is I need some way to “reset” the state variables for a new scene, that trigger would likely come externally. I have separate code for scripts and view scripts as an orthogonal independent entity. The script fields and routes get translated as part of the protoexpander (or elided).  I have a separate script Script.js which is supposed to convert VRMLScript to something the browser can handle.  I need help understanding the standard to do further development on Script.js.  No handling of AS or directOutput except what Cobweb might handle in it’s scripts (so Script.js is not needed for Cobweb).  I mainly take the field and produce setters and getters and variables in a JavaScript function, instantiate  the function, then run “stupid” routes—a loop to take fromfields and put them in tofields.
5) If V4 does not have Protos, then the prototype expander may be a good way to bring protos into non-proto world by  removing them and replacing them with equivalent code, providing a bridge from 3.3. to 4.0.  It is not a desireable feature, but a necessary feature, I think, until Cobweb or a templating library takes over old content.

This is very good.  I have not seen a real requirements document for the prototype expander, so I’ve been winging it.  Now it’s coming down to the last part of the project and I’m thinking of calling for help from topcoder.  Basically, I need help with H-Anim protos and Nested ProtoInstances from the same ProtoDeclare.   Script would be handled by someone more familiar with the standard (and I’ve been begging for help with scripts if you haven’t noticed).  We don’t have to use the X3D script tag with JSON Scripts, so the tag name conflict is out of the picture.


Sent from Mail for Windows 10

From: Leonard Daly
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20160624/eaa9deb9/attachment-0001.html>