<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;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
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;}
.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;}
--></style></head><body lang=EN-US link=blue vlink="#954F72"><div class=WordSection1><p class=MsoNormal>What is the likelihood of resurrecting either X3dToES5.xslt or X3dToES6.xslt to handle this? This is likely a severe problem with X3DJSONLD in general, but not sure which serializers it might affect yet. It would probably match X3DJSAIL architecture a lot better if we used a stylesheet, but I’m not in charge of Don’s time, and I think it might be better spent creating a X3dToPython.xslt (or X3DPythonSAIL that can use pipelining—either with PyJNIUs or without).</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>What’s the priority for generating JavaScript from X3DJSAIL vis a vi Python from X3DJSAIL?</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>I might get in to the stylesheet business again if Don’s busy with X3dToPython.xslt, and I would be probably the last person to touch the JavaScript stylesheets.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>In otherwords, I’m pretty much ready to bail on X3DJSONLD Serializers and go with stylesheets (except perhaps for the web and DOM2JSONSerializer.js)</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Or perhaps I should look at the ProtoBody in the serializer? For the actual child? What if it’s a switch?</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Should we be looking to generate the X3dTo*.xslt from a more unified source or two? IDK, Don’s probably the best one to comment. Perhaps that work is already done?</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>John</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><o:p> </o:p></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:yottzumm@gmail.com">John Carlson</a><br><b>Sent: </b>Tuesday, October 16, 2018 9:21 PM<br><b>To: </b><a href="mailto:x3d-public@web3d.org">X3D Graphics public mailing list</a><br><b>Subject: </b>RE: X3DJSAIL, possible bug in JS generation</p></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>I confirmed that the override is there, and it is set to setMaterial. So there’s no current way to addShaders, since I believe that setMaterial is the most common containerField. How does X3dToJava.xslt handle this choice for containerFields? We can discuss this at the meeting tomorrow at 2pm PST, but this is likely a widespread problem with mapToMethod*.js<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>The parent element is Appearance, and the ProtoInstance is the child. How can we automatically choose either setMaterial or addShaders? Do I need to look at the ProtoBody?<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Does this have something to do with ExternProtoDeclare validation? Would X3DUOM resolve it if I just looked closer (and put it in mapToMethod.js which is autogenerated?)<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Seems like we’re getting to some really gnarly bugs which require looking at the scenegraph or extended scenegraph in more detail.<o:p></o:p></p><p class=MsoNormal><br>Thanks,<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>John<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<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></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:yottzumm@gmail.com">John Carlson</a><br><b>Sent: </b>Tuesday, October 16, 2018 9:01 PM<br><b>To: </b><a href="mailto:x3d-public@web3d.org">X3D Graphics public mailing list</a><br><b>Subject: </b>X3DJSAIL, possible bug in JS generation<o:p></o:p></p></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>It looks like the JS generation (JavaScriptSerializer.js) may have an issue with addShaders being<o:p></o:p></p><p class=MsoNormal>generated for ProtoInstanceObject’s. This happens when mapToMethod2.js has no override for the ProtoInstance child I think, but<o:p></o:p></p><p class=MsoNormal>I will check soon.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Here is the JS code:<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>coderextreme@DESKTOP-DOPK2VD MINGW64 /c/x3d-code/www.web3d.org/x3d/stylesheets/java/nashorn/examples<o:p></o:p></p><p class=MsoNormal>$ grep addShaders *<o:p></o:p></p><p class=MsoNormal>HelloWorldProgramOutput.Nashorn.js: .addShaders(new ProgramShaderObject().setDEF("TestShader1")<o:p></o:p></p><p class=MsoNormal>HelloWorldProgramOutput.Nashorn.js: .addShaders(new ComposedShaderObject().setDEF("TestShader4")<o:p></o:p></p><p class=MsoNormal><br>Here is the original Java code:<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>HelloWorldProgram.java: .addShaders(new ProgramShaderObject("TestShader1")<o:p></o:p></p><p class=MsoNormal>HelloWorldProgram.java: .addShaders(new ProtoInstanceObject("ShaderProto","TestShader3"))<o:p></o:p></p><p class=MsoNormal>HelloWorldProgram.java: .addShaders(new ComposedShaderObject("TestShader4")<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Here is the generated Java code:<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>HelloWorldProgramOutput.java: .addShaders(new ProgramShaderObject()<o:p></o:p></p><p class=MsoNormal>HelloWorldProgramOutput.java: .addShaders(new ProtoInstanceObject("ShaderProto", "TestShader3"))<o:p></o:p></p><p class=MsoNormal>HelloWorldProgramOutput.java: .addShaders(new ComposedShaderObject()<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p></div></body></html>