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

[Andreas Plesch]

On Mon, Mar 5, 2018 at 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.

Here is what I understand about containerfield, probably incompletely:

>From looking at the JSON schema, it appears that json encoding does
not need a containerfield property for any node.
This means that it is generally impossible to have an exact roundtrip
XML/DOM-JSON-XML/DOM if XML/DOM has unnecessary containerfield
attributes since those will not be preserved in the json structure.
It is possible to have functional roundtrips, however.

For JSON -> XML/DOM it should be ok to just always provide a
containerfield. It may slow down DOM parsing in some X3D browsers, and
leads to verbose XML when serialized.
Perhaps the only comprehensive way to then omit unnecessary
containerfield atttributes is to use the XML schema to assemble a list
of default containerfield values for each x3d node which would take
some time to learn how to do but is a one time effort. x_ite has a
.getContainerField() method for each node which returns the default
containerField.
It should also be possible to generate the limited set of nodes which
can have children which potentially need containerField, or the set of
nodes which never need containerfield in their children. Perhaps such
a list already exists ?

-Andreas



>
>
>
> John
>
>
>
> Sent from Mail for Windows 10
>
>
>
> From: John Carlson
> Sent: Monday, March 5, 2018 1:22 PM
> To: Andreas Plesch
> Cc: Holger Seelig; X3D Graphics public mailing list; Don Brutzman
> 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/main/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/Reference/Lexical_grammar#Automatic_semicolon_insertion
> ,
> https://www.theregister.co.uk/2018/01/12/javascript_technical_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
>
>



-- 
Andreas Plesch
Waltham, MA 02453