[x3d-public] DOM2JSONSerializer.js (and X3DJSONLD.js)

[John Carlson]

On Mar 5, 2018 7:41 PM, "Andreas Plesch" <andreasplesch at gmail.com> wrote:

I believe Titania, Holger's X3D editor, has now X3D json export and
serializing although I did not yet try it. So it may be possible to follow
its behavior. In theory, serializing should be decoupled from parsing as
long as there is a complete description/schema ?


I don't rely on complete schema.   Just pieces.  Oh well.


Ideally, attributes in the DOM should only be filled if they have
non-default values but the DOM is a in memory structure anyway. Only when
serializing out to XML this becomes more of a consideration in order to
follow the spec.

I rely on what's in Dom for JSON generation.   Right now, I get Dom values
from Json because of history.


Perhaps it is easier to have a second phase which removes such default
value attributes after serialization using the X3D schema.


Maybe


Not sure if the json structure requires the same/more/less/any
containerfield disambiguations than dom. This was likely discussed. It
seems cleaner to go from X3D rather than DOM to json ?


Same I think.   I plan to put a domparser in front of X3D to create Dom.
And then to JSON.   So I won't come from initial Json values


Inversely, the x_ite json parser probably should go from json straight to
X3D nodes/fields bypassing the DOM, similar to the other parsers.


Yes, but I am lazy and want to use existing code.

John


-Andreas

On Mar 5, 2018 5:25 PM, "John Carlson" <yottzumm at gmail.com> wrote:

I have at least one more task on DOM2JSONSerializer.js.  I need to identify
the container fields -parts and -shaders at least—instead of using
-children.  This was done in the other serializers with mapToMethod*.js.  I
could use those again, but I will have to take off the “set” and “add”.
What would be cool is if we could identify these from the original JSON.
For some reason, these aren’t coming across to the DOMSerializer.js I don’t
think.   So there’s a failing in X3DJSONLD.js…beware X_ITE!   X3DJSONLD.js
(and thereby JSONParser.js) is messed up! So the DOM won’t contain
containerField attributes in many cases.  I am not sure what cases this
matters in.



Perhaps it’s time to revert some changes to X3DJSONLD.js to include more
containerFields.  Hmm.



I don’t think this is a death knell, but it probably will affect JSON
schema validation and roundtrip comparison!



Time for me to think on this.   What cases should containerField get filled
in in the DOM?  I have been trying to minimize them, but it shot me in the
foot, so now I’m tending to maximize it.



John



Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for Windows
10



*From: *John Carlson <yottzumm at gmail.com>
*Sent: *Monday, March 5, 2018 1:22 PM
*To: *Andreas Plesch <andreasplesch at gmail.com>
*Cc: *Holger Seelig <holger.seelig at yahoo.de>; X3D Graphics public mailing
list <x3d-public at web3d.org>; Don Brutzman <brutzman at nps.edu>
*Subject: *Re: Effects of scrunching all VRMLscript in a Script into a
singleline, X_ITE.



Thanks for your explanation, Andreas.  It looks like I should proceed with
good speed at coming up with a replacement for X3dToJson.xslt.    which is
almost complete, if someone wants to help...



https://github.com/coderextreme/X3DJSONLD/blob/master/src/ma
in/node/DOM2JSONSerializer.js



One of the last tasks is identifying which arrays should be objects.



John



On Mar 5, 2018 12:57 PM, "Andreas Plesch" <andreasplesch at gmail.com> wrote:

One (fatal) issue with just merging all lines into a single line are
caused by ecmascript single line comments:

// helpful explanation
var radius1 = outerRadius - toothDepth / 2;
...

versus

// helpful explanation var radius1 = outerRadius - toothDepth / 2; ...

which never evaluates radius1.

If all comments would be replaced by multiline commenting  as in /*
helpful explanation */ , the single script line may work (if all lines
are carefully terminated by semicolons which is not required in many
situations in ecmascript:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe
rence/Lexical_grammar#Automatic_semicolon_insertion
, https://www.theregister.co.uk/2018/01/12/javascript_technica
l_group_semicolons/).

It is definitely safest (and probably unavoidable) to preserve line
breaks in the json.

X_ITE itself cannot really do much more than eval the provided script as is.

-Andreas




On Mon, Mar 5, 2018 at 11:23 AM, John Carlson <yottzumm at gmail.com> wrote:
> Holger, can you look at X_ITE to see the effect of scrunching all the
> VRMLScript in a Script into a single line?  I’m having issues with that
> right now, with JSON.  Thanks!
>
>
>
> John



--
Andreas Plesch
Waltham, MA 02453
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20180305/23bc8549/attachment.html>