<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>