<div dir="auto">It's not that JSON doesn't have container fields.   It's just that they're probably called field labels and start with a -.<div dir="auto"><br></div><div dir="auto">John</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mar 6, 2018 12:09 PM, "Andreas Plesch" <<a href="mailto:andreasplesch@gmail.com">andreasplesch@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Tue, Mar 6, 2018 at 10:46 AM, Andreas Plesch <<a href="mailto:andreasplesch@gmail.com">andreasplesch@gmail.com</a>> wrote:<br>
> On Mon, Mar 5, 2018 at 5:25 PM, John Carlson <<a href="mailto:yottzumm@gmail.com">yottzumm@gmail.com</a>> wrote:<br>
>> I have at least one more task on DOM2JSONSerializer.js.  I need to identify<br>
>> ...<br>
>> Time for me to think on this.   What cases should containerField get filled<br>
>> in in the DOM?  I have been trying to minimize them, but it shot me in the<br>
>> foot, so now I’m tending to maximize it.<br>
><br>
> Here is what I understand about containerfield, probably incompletely:<br>
><br>
> From looking at the JSON schema, it appears that json encoding does<br>
> not need a containerfield property for any node.<br>
> This means that it is generally impossible to have an exact roundtrip<br>
> XML/DOM-JSON-XML/DOM if XML/DOM has unnecessary containerfield<br>
> attributes since those will not be preserved in the json structure.<br>
> It is possible to have functional roundtrips, however.<br>
><br>
> For JSON -> XML/DOM it should be ok to just always provide a<br>
> containerfield. It may slow down DOM parsing in some X3D browsers, and<br>
> leads to verbose XML when serialized.<br>
> Perhaps the only comprehensive way to then omit unnecessary<br>
> containerfield atttributes is to use the XML schema to assemble a list<br>
> of default containerfield values for each x3d node which would take<br>
> some time to learn how to do but is a one time effort. x_ite has a<br>
> .getContainerField() method for each node which returns the default<br>
> containerField.<br>
> It should also be possible to generate the limited set of nodes which<br>
> can have children which potentially need containerField, or the set of<br>
> nodes which never need containerfield in their children. Perhaps such<br>
> a list already exists ?<br>
<br>
Digging found this list of nodes:<br>
<br>
<a href="http://www.web3d.org/x3d/content/examples/X3dSceneAuthoringHints.html#containerField" rel="noreferrer" target="_blank">http://www.web3d.org/x3d/<wbr>content/examples/<wbr>X3dSceneAuthoringHints.html#<wbr>containerField</a><br>
<br>
which is what I had in mind.<br>
<br>
I think grouping nodes may also need to be listed since their xml<br>
children may either be values of their children field (the default) or<br>
the value of their SFNode metadata field.<br>
<br>
-Andreas<br>
<br>
<br>
><br>
> -Andreas<br>
><br>
><br>
><br>
>><br>
>><br>
>><br>
>> John<br>
>><br>
>><br>
>><br>
>> Sent from Mail for Windows 10<br>
>><br>
>><br>
>><br>
>> From: John Carlson<br>
>> Sent: Monday, March 5, 2018 1:22 PM<br>
>> To: Andreas Plesch<br>
>> Cc: Holger Seelig; X3D Graphics public mailing list; Don Brutzman<br>
>> Subject: Re: Effects of scrunching all VRMLscript in a Script into a<br>
>> singleline, X_ITE.<br>
>><br>
>><br>
>><br>
>> Thanks for your explanation, Andreas.  It looks like I should proceed with<br>
>> good speed at coming up with a replacement for X3dToJson.xslt.    which is<br>
>> almost complete, if someone wants to help...<br>
>><br>
>><br>
>><br>
>> <a href="https://github.com/coderextreme/X3DJSONLD/blob/master/src/main/node/DOM2JSONSerializer.js" rel="noreferrer" target="_blank">https://github.com/<wbr>coderextreme/X3DJSONLD/blob/<wbr>master/src/main/node/<wbr>DOM2JSONSerializer.js</a><br>
>><br>
>><br>
>><br>
>> One of the last tasks is identifying which arrays should be objects.<br>
>><br>
>><br>
>><br>
>> John<br>
>><br>
>><br>
>><br>
>> On Mar 5, 2018 12:57 PM, "Andreas Plesch" <<a href="mailto:andreasplesch@gmail.com">andreasplesch@gmail.com</a>> wrote:<br>
>><br>
>> One (fatal) issue with just merging all lines into a single line are<br>
>> caused by ecmascript single line comments:<br>
>><br>
>> // helpful explanation<br>
>> var radius1 = outerRadius - toothDepth / 2;<br>
>> ...<br>
>><br>
>> versus<br>
>><br>
>> // helpful explanation var radius1 = outerRadius - toothDepth / 2; ...<br>
>><br>
>> which never evaluates radius1.<br>
>><br>
>> If all comments would be replaced by multiline commenting  as in /*<br>
>> helpful explanation */ , the single script line may work (if all lines<br>
>> are carefully terminated by semicolons which is not required in many<br>
>> situations in ecmascript:<br>
>> <a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Lexical_grammar#Automatic_semicolon_insertion" rel="noreferrer" target="_blank">https://developer.mozilla.org/<wbr>en-US/docs/Web/JavaScript/<wbr>Reference/Lexical_grammar#<wbr>Automatic_semicolon_insertion</a><br>
>> ,<br>
>> <a href="https://www.theregister.co.uk/2018/01/12/javascript_technical_group_semicolons/" rel="noreferrer" target="_blank">https://www.theregister.co.uk/<wbr>2018/01/12/javascript_<wbr>technical_group_semicolons/</a>).<br>
>><br>
>> It is definitely safest (and probably unavoidable) to preserve line<br>
>> breaks in the json.<br>
>><br>
>> X_ITE itself cannot really do much more than eval the provided script as is.<br>
>><br>
>> -Andreas<br>
>><br>
>><br>
>><br>
>><br>
>> On Mon, Mar 5, 2018 at 11:23 AM, John Carlson <<a href="mailto:yottzumm@gmail.com">yottzumm@gmail.com</a>> wrote:<br>
>>> Holger, can you look at X_ITE to see the effect of scrunching all the<br>
>>> VRMLScript in a Script into a single line?  I’m having issues with that<br>
>>> right now, with JSON.  Thanks!<br>
>>><br>
>>><br>
>>><br>
>>> John<br>
>><br>
>><br>
>><br>
>> --<br>
>> Andreas Plesch<br>
>> Waltham, MA 02453<br>
>><br>
>><br>
><br>
><br>
><br>
> --<br>
> Andreas Plesch<br>
> Waltham, MA 02453<br>
<br>
<br>
<br>
--<br>
Andreas Plesch<br>
Waltham, MA 02453<br>
</blockquote></div></div>