<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:"Times New Roman \,serif";}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;
color:windowtext;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman",serif;
color:black;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:105735089;
mso-list-type:hybrid;
mso-list-template-ids:-1436274160 -1 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
{mso-level-text:"%1\)";
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style></head><body lang=EN-US link=blue vlink="#954F72"><div class=WordSection1><p class=MsoNormal>Leonard, I will try to answer all of your questions.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span style='mso-list:Ignore'>1)<span style='font:7.0pt "Times New Roman"'> </span></span><![endif]> In order, as opposed to pre-order or post-order traversal of a tree. This assumes you have a left and right side of the tree, and nodes are visited going around the left to right side of the tree, visiting the nodes when the path reaches the bottom part of a node. It’s not done when constructing the JSON (yet), because I traverse the arrays with a for loop, constructing a new object, like:</p><p class=MsoListParagraph>If (old object is an array) </p><p class=MsoListParagraph> New object is an *new* array</p><p class=MsoListParagraph>Else</p><p class=MsoListParagraph> New object is an *<b>new</b>* object</p><p class=MsoListParagraph>For (key in old object) {</p><p class=MsoListParagraph> New object [ key ] = processing(old object [ key ])</p><p class=MsoListParagraph><o:p> </o:p></p><p class=MsoListParagraph>Now there’s often a lot of processing for old object [ key ] before it becomes a new object [ key ] for many of the types of node I handle I handle in the prototype expander some of those produce arrays currently. So if I’m in the middle of processing an array and I get an array out of processing, what do I do? For objects, this is not an issue. However, for arrays, I cannot just stick an array into an array per the standard. So what do I do? I can keep track of another index, say array element, </p><p class=MsoListParagraph> For (arrayelement in “processing (old object [ key ]”) </p><p class=MsoListParagraph> New object [ key + array element ] = “processing(old object [key])” [ array element ]</p><p class=MsoListParagraph><o:p> </o:p></p><p class=MsoListParagraph>Where quotes indicate a variable, not a function call. Then I would have to keep track of another key2 for the next array I processed, since, array element will be reset to 0.</p><p class=MsoListParagraph><o:p> </o:p></p><p class=MsoListParagraph>This ends up being really ugly code and does not lead to understand what is really happening. Which the first set of code describes perfectly. I also may have to handle the case where processing returns an empty object. The code is so ugly, I would prefer to clean it up by putting it in in an unrelated script which processes all nested arrays into flat arrays (we may want to provide this anyway for people to comply with current standard). Let’s call this new code FLATTENER.</p><p class=MsoListParagraph><o:p> </o:p></p><p class=MsoListParagraph>I agree that FLATTENER is likely the best solution for this, and it can notify the user if there are unflatttened arrays if desired. However, I’m lazy, and I’m always looking for a better, quicker solution. Got one? I think FLATTENER should be done AFTER the prototype expander. But before a loader or schema check.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span style='mso-list:Ignore'>2)<span style='font:7.0pt "Times New Roman"'> </span></span><![endif]>Yes, Prototype Expander is the driving request.</p><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span style='mso-list:Ignore'>3)<span style='font:7.0pt "Times New Roman"'> </span></span><![endif]>The Prototype Expander handles the JSON encoding an the code is open source and found in this repository: <a href="https://github.com/coderextreme/X3DJSONLD/blob/master/PrototypeExpander.js">https://github.com/coderextreme/X3DJSONLD/blob/master/PrototypeExpander.js</a> It takes Protos and extern Protos and makes non-proto code by duplicating prototobody code for each protoinstance. This code has never been released under a different license, and is my original code—be warned that other code in that repository may have different licenses, and is a collection of code from the X3D Resource Example sites for the most part. I can help nail down which code is mine and which is contributed (the JS is mine, the JSON and X3D may be others). The code is written JavaScript, and is still in alpha testing. You are welcome to report issues or nail down bugs with my help. It can run standalone (see PPP.js) or in a browser/server fashion (see loaderJQuery.js/PrototypeExpander.js&app.js). There is standalone JSON to XML converter called json2x3d.js and which is reliant on X3DJSONLD.js script.</p><p class=MsoListParagraph>3b) I have been working on integrating Inlines into the X3D JSON Loader, so I currently have two inline based functions which could be used either to incorporate new inlines in loaderJQuery.js, or probably arbitrary JSON code. I do not currently handle inline XML. We would have to decide where to place the FLATTENER code, but soon after the proto expander would be good.</p><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span style='mso-list:Ignore'>4)<span style='font:7.0pt "Times New Roman"'> </span></span><![endif]>You would have to run the code through the protoexpander to load protos on the fly. I don’t currently do that, but state variables could be kept around for future use (likely recommended, I need to make that change). What I am worried about is I need some way to “reset” the state variables for a new scene, that trigger would likely come externally. I have separate code for scripts and view scripts as an orthogonal independent entity. The script fields and routes get translated as part of the protoexpander (or elided). I have a separate script Script.js which is supposed to convert VRMLScript to something the browser can handle. I need help understanding the standard to do further development on Script.js. No handling of AS or directOutput except what Cobweb might handle in it’s scripts (so Script.js is not needed for Cobweb). I mainly take the field and produce setters and getters and variables in a JavaScript function, instantiate the function, then run “stupid” routes—a loop to take fromfields and put them in tofields.</p><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span style='mso-list:Ignore'>5)<span style='font:7.0pt "Times New Roman"'> </span></span><![endif]>If V4 does not have Protos, then the prototype expander may be a good way to bring protos into non-proto world by removing them and replacing them with equivalent code, providing a bridge from 3.3. to 4.0. It is not a desireable feature, but a necessary feature, I think, until Cobweb or a templating library takes over old content.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>This is very good. I have not seen a real requirements document for the prototype expander, so I’ve been winging it. Now it’s coming down to the last part of the project and I’m thinking of calling for help from topcoder. Basically, I need help with H-Anim protos and Nested ProtoInstances from the same ProtoDeclare. Script would be handled by someone more familiar with the standard (and I’ve been begging for help with scripts if you haven’t noticed). We don’t have to use the X3D script tag with JSON Scripts, so the tag name conflict is out of the picture.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Sent from <a href="https://go.microsoft.com/fwlink/?LinkId=550986">Mail</a> for Windows 10</p><p class=MsoNormal><span style='font-size:12.0pt;font-family:"Times New Roman",serif'><o:p> </o:p></span></p><div style='mso-element:para-border-div;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:Leonard.Daly@realism.com">Leonard Daly</a><br><b>Sent: </b>Wednesday, June 22, 2016 10:02 PM<br><b>To: </b><a href="mailto:yottzumm@gmail.com">John Carlson</a>; <a href="mailto:x3d-public@web3d.org">X3D Graphics public mailing list</a>; <a href="mailto:x3d@web3d.org">X3D</a><br><b>Subject: </b>Re: [x3d] Proposal for X3D JSON encoding. Array of arrays foranyarray</p></div><p class=MsoNormal><span style='font-size:12.0pt;font-family:"Times New Roman",serif'><o:p> </o:p></span></p><p class=MsoNormal style='margin-bottom:12.0pt'><span style='font-size:12.0pt;font-family:"Times New Roman",serif'>John,<br><br>There are a few things I am not grasping. I'm asking these questions to make sure I fully understand the implications and impetuous for your proposal. I am also concerned because you mention code. Code in the ISO structure would be a new thing for the Consortium. It is not something we have done before, and the Consortium needs to make sure it understands everything before embarking on such a path.<br><br>1) "...when translating from the JSON encoding to something else, or process the JSON, we assume that the arrays flatten in an in-order manner?"<br>It sounds like you are serializing the MFNode where you drill down each time an element is an MFNode until an SFNode is reached, the go back up taking the next, deepest MFNode element to the bottom, repeating until all of the SFNode elements have been processed. That would take<br><br>[[[A,B]],[C,[D,E]], F] <br><br>and turn it into [A,B,C,D,E, F]<br><br>where A-F are SFNodes.<br><br>Why can't/shouldn't that be done when constructing the JSON. A simple example would be great.<br><br><br>2) Is the prototype expander code the driving force behind this request? (3) and (4) are probably only necessary if this answer is yes. If it is no, what is the driver for expanding the structure of MFNode?<br><br>3) What is the prototype expanded code that you are referring to. Is this something you have written that parses an X3D file (which encoding?) and does something with PROTOs? Is the code platform-independent? Is this intended to run stand-alone at a particular point in the work flow or can it be integrated into a dynamic scene creation, especially if part of the scene comes during a download after the initial scene is running?<br><br><br>4) What does the prototype expander code do? How does it interact handle code constructed on the fly? How does it handle X3D Script nodes? Does it depend/handle "AS" and/or directOutput?<br><br>5) If X3D V4 does not have PROTOs, would this be necessary?<br><br><br>Leonard Daly<br><br><br><br></span><span style='font-size:12.0pt;font-family:"Times New Roman",serif'><o:p></o:p></span></p><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><p class=MsoNormal>Then I would step back and say can we just have it for MFNodes in the JSON encoding, and when translating from the JSON encoding to something else, or process the JSON, we assume that the arrays flatten in an in-order manner? I do that anyway for MFNodes in the JSON Loader, it would just be nice not to have a separate pass or more code to deal with it in the prototype expander. If the prototype expander is considered throwaway code or proof-of-concept, then I don’t think it really matters. If we want to make the prototype expander into production quality code, then we need to account for the performance of the code, and likely this means writing more code, which means longer download times for the code, which may mean, over the times it’s downloaded, quite a few bytes. On the other hand, if we go the other way, we have to consider the processing time for the schema verification and schema download time. I don’t really have a good feel for this either way. Perhaps we could go both ways and measure the difference? We really need some good performance metrics for this, or someone with an eye for performance. Of the cuff, I would probably say put in a Group node into the output of the prototype expander would be the fastest approach, and only put in a Group node when you are going to have a an array of arrays. That way, we hope that the processing is done on the client instead of a shared system.<o:p></o:p></p><p class=MsoNormal> </p><p class=MsoNormal>Any other solutions?<o:p></o:p></p><p class=MsoNormal> </p><p class=MsoNormal>Thanks,<o:p></o:p></p><p class=MsoNormal> </p><p class=MsoNormal>John<o:p></o:p></p><p class=MsoNormal> </p><p class=MsoNormal>Sent from <a href="https://go.microsoft.com/fwlink/?LinkId=550986">Mail</a> for Windows 10<o:p></o:p></p><p class=MsoNormal><span style='font-size:12.0pt;font-family:"Times New Roman ,serif",serif'> </span></p><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b>From: </b><a href="mailto:roy.walmsley@ntlworld.com">Roy Walmsley</a><br><b>Sent: </b>Wednesday, June 22, 2016 1:12 PM<br><b>To: </b><a href="mailto:yottzumm@gmail.com">'John Carlson'</a>; <a href="mailto:Leonard.Daly@realism.com">'Leonard Daly'</a><br><b>Cc: </b><a href="mailto:x3d@web3d.org">'X3D Graphics member mailing list'</a><br><b>Subject: </b>RE: [x3d] Proposal for X3D JSON encoding. Array of arrays foranyarray<o:p></o:p></p></div><p class=MsoNormal><span style='font-size:12.0pt;font-family:"Times New Roman ,serif",serif'> </span></p><p class=MsoNormal><span lang=EN-GB style='color:#1F497D'>John,</span><o:p></o:p></p><p class=MsoNormal><span lang=EN-GB style='color:#1F497D'> </span></p><p class=MsoNormal><span lang=EN-GB style='color:#1F497D'>We briefly highlighted this topic during our WG meeting today. The concern is that this proposed change could have significant implications.</span><o:p></o:p></p><p class=MsoNormal><span lang=EN-GB style='color:#1F497D'> </span></p><p class=MsoNormal><span lang=EN-GB style='color:#1F497D'>For example, the abstract specification <a href="http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/fieldsDef.html#X3DAbstractField">19775-1, in 5.2.2 X3DArrayField</a> states “MFxxxx fields may zero or more values, each of which shall be of the type indicated by the corresponding SFxxxx field type.”. This effectively rules out incorporating arrays within arrays. (NOTE: The quotation above is missing a verb! Another specification comment required!).</span><o:p></o:p></p><p class=MsoNormal><span lang=EN-GB style='color:#1F497D'> </span></p><p class=MsoNormal><span lang=EN-GB style='color:#1F497D'>If you seriously wish to propose this change then the first formal step is to submit a <a href="http://www.web3d.org/content/web3d-standards-comment-form">specification comment</a>. I would suggest that this could be based on the section of the abstract specification highlighted above. Then, I would follow the Consortium standard procedure of raising a Mantis issue, which would then be discussed by the WG, who would consider all the pros and cons associated with this proposal, and come to a resolution.</span><o:p></o:p></p><p class=MsoNormal><span lang=EN-GB style='color:#1F497D'> </span></p><p class=MsoNormal><span lang=EN-GB style='color:#1F497D'>I have to revert back to the 19775-1 specification because all the encodings in the 19776 series are written to ensure that content written in any one of the encodings conforms to the requirements of the abstract specification 19775-1. This commonality permits scenes written in one encoding to be easily converted to another encoding. It is not permitted to have, for example, different MFxxxx field content models in the JSON encoding than in the other encodings, or the abstract specification.</span><o:p></o:p></p><p class=MsoNormal><span lang=EN-GB style='color:#1F497D'> </span></p><p class=MsoNormal><span lang=EN-GB style='color:#1F497D'>Roy</span><o:p></o:p></p><p class=MsoNormal><span lang=EN-GB style='color:#1F497D'> </span></p><p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma",sans-serif'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma",sans-serif'> x3d [<a href="mailto:x3d-bounces@web3d.org">mailto:x3d-bounces@web3d.org</a>] <b>On Behalf Of </b>John Carlson<br><b>Sent:</b> 22 June 2016 08:34<br><b>To:</b> Leonard Daly<br><b>Cc:</b> X3D Graphics member mailing list<br><b>Subject:</b> Re: [x3d] Proposal for X3D JSON encoding. Array of arrays for anyarray</span><o:p></o:p></p><p class=MsoNormal><span lang=EN-GB style='font-family:"Times New Roman ,serif",serif'> </span></p><p><span lang=EN-GB>Again, I am only really asking for MFNode arrays to contain MFNodes in the JSON encoding/schema. </span></p><div><p class=MsoNormal><span lang=EN-GB>On Jun 22, 2016 3:30 AM, "John Carlson" <<a href="mailto:yottzumm@gmail.com">yottzumm@gmail.com</a>> wrote:</span></p><p><span lang=EN-GB>Leonard wrote:</span></p><p><span lang=EN-GB>> My concern is that if the JSON encoding supports this structure does that mean the structure needs to also appear in the other encodings? If so, how would that be done?</span></p></div><p><span lang=EN-GB>I am not so sure the other encodings don't already support it. Certainly XML does this implicitly. Perhaps some of the binary encodings don't? idk.</span><o:p></o:p></p><p class=MsoNormal><span style='font-size:12.0pt;font-family:"Times New Roman ,serif",serif'> </span></p></blockquote><p class=MsoNormal><span style='font-family:"Times New Roman",serif'><o:p> </o:p></span></p><p><o:p> </o:p></p><p class=MsoNormal><span style='font-family:"Times New Roman",serif'>-- <br></span><b><span style='font-size:13.5pt;font-family:"Times New Roman",serif;color:#333366'>Leonard Daly</span></b><span style='font-family:"Times New Roman",serif;color:#333366'><br>3D Systems & Cloud Consultant<br>X3D Co-Chair on Sabbatical<br>LA ACM SIGGRAPH Chair<br>President, Daly Realism - <i>Creating the Future</i> </span><span style='font-family:"Times New Roman",serif'><o:p></o:p></span></p><p class=MsoNormal><span style='color:black'><o:p> </o:p></span></p></div></body></html>