<div dir="auto"><div><br><div class="gmail_extra"><br><div class="gmail_quote">On Mar 5, 2018 7:41 PM, "Andreas Plesch" <<a href="mailto:andreasplesch@gmail.com">andreasplesch@gmail.com</a>> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div>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 ?</div></div></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">I don't rely on complete schema.  Just pieces. Oh well.</div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"></div></div></blockquote></div></div></div><div dir="auto">I rely on what's in Dom for JSON generation.  Right now, I get Dom values from Json because of history.</div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div dir="auto"><br></div><div dir="auto">Perhaps it is easier to have a second phase which removes such default value attributes after serialization using the X3D schema.</div><div dir="auto"></div></div></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">Maybe</div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div dir="auto"><br></div><div dir="auto">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 ?</div></div></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">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</div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div dir="auto"><br></div><div dir="auto">Inversely, the x_ite json parser probably should go from json straight to X3D nodes/fields bypassing the DOM, similar to the other parsers.</div></div></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">Yes, but I am lazy and want to use existing code.</div><div dir="auto"><br></div><div dir="auto">John</div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><font color="#888888"><div dir="auto"><br></div><div dir="auto">-Andreas</div></font><div class="elided-text"><div dir="auto"><br></div><div dir="auto"><div class="gmail_extra" dir="auto"><div class="gmail_quote">On Mar 5, 2018 5:25 PM, "John Carlson" <<a href="mailto:yottzumm@gmail.com" target="_blank">yottzumm@gmail.com</a>> wrote:<br type="attribution"><blockquote class="m_2761760103333855921m_3077800953037009051m_-7103071021932475102quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="#954F72"><div class="m_2761760103333855921m_3077800953037009051m_-7103071021932475102m_-8100230481245975143WordSection1"><p class="MsoNormal">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.</p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">Perhaps it’s time to revert some changes to X3DJSONLD.js to include more containerFields. Hmm.</p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">I don’t think this is a death knell, but it probably will affect JSON schema validation and roundtrip comparison!</p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">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.</p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">John</p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">Sent from <a href="https://go.microsoft.com/fwlink/?LinkId=550986" target="_blank">Mail</a> for Windows 10</p><p class="MsoNormal"><u></u> <u></u></p><div style="border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0in 0in 0in"><p class="MsoNormal" style="border:none;padding:0in"><b>From: </b><a href="mailto:yottzumm@gmail.com" target="_blank">John Carlson</a><br><b>Sent: </b>Monday, March 5, 2018 1:22 PM<br><b>To: </b><a href="mailto:andreasplesch@gmail.com" target="_blank">Andreas Plesch</a><br><b>Cc: </b><a href="mailto:holger.seelig@yahoo.de" target="_blank">Holger Seelig</a>; <a href="mailto:x3d-public@web3d.org" target="_blank">X3D Graphics public mailing list</a>; <a href="mailto:brutzman@nps.edu" target="_blank">Don Brutzman</a><br><b>Subject: </b>Re: Effects of scrunching all VRMLscript in a Script into a singleline, X_ITE.</p></div><p class="MsoNormal"><u></u> <u></u></p><div><p class="MsoNormal">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...</p><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal"><a href="https://github.com/coderextreme/X3DJSONLD/blob/master/src/main/node/DOM2JSONSerializer.js" target="_blank">https://github.com/coderextrem<wbr>e/X3DJSONLD/blob/master/src/ma<wbr>in/node/DOM2JSONSerializer.js</a></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">One of the last tasks is identifying which arrays should be objects.</p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">John</p></div></div><div><p class="MsoNormal"><u></u> <u></u></p><div><p class="MsoNormal">On Mar 5, 2018 12:57 PM, "Andreas Plesch" <<a href="mailto:andreasplesch@gmail.com" target="_blank">andreasplesch@gmail.com</a>> wrote:</p></div></div><p class="MsoNormal" style="margin-left:4.8pt">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" target="_blank">https://developer.mozilla.org/<wbr>en-US/docs/Web/JavaScript/Refe<wbr>rence/Lexical_grammar#Automati<wbr>c_semicolon_insertion</a><br>, <a href="https://www.theregister.co.uk/2018/01/12/javascript_technical_group_semicolons/" target="_blank">https://www.theregister.co.uk/<wbr>2018/01/12/javascript_technica<wbr>l_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" target="_blank">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</p><p class="MsoNormal"><u></u> <u></u></p></div></div></blockquote></div><br></div></div></div></div>
</blockquote></div><br></div></div></div>