<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;}
.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>> It's important to note that this thread is mainly about DEF in VRML. Which may have different behavior than DEF in XML and JSON.   </p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>If DEFs have any different behavior in any encoding it is an error. Please notice how the DEFs are used in vrml as a name for a reusable node component and a target.</p><p class=MsoNormal>XML id is only a element identifier or a target. </p><p class=MsoNormal>Only one DEF or ID string is legal, although as Don pointed out, in general html, the browser may pass dup id strings and just use the first or maybey the last one if the string is referenced. No x3d should allow duplicate DEFs.</p><p class=MsoNormal>Joe</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></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>Thursday, March 26, 2020 1:25 PM<br><b>To: </b><a href="mailto:brutzman@nps.edu">Don Brutzman</a>; <a href="mailto:Leonard.Daly@realism.com">Leonard Daly</a><br><b>Cc: </b><a href="mailto:x3d-public@web3d.org">X3D Graphics public mailing list</a><br><b>Subject: </b>Re: [x3d-public] Finding more than one use of a DEF in VRML -encoding/language portability</p></div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>unique DEFs for each protoexpanded ProtoBody means unique nodes in routes.  Which means unique nodes in Scripts. Which mean protoexpansion comes before routes comes before scripts.</p></div><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal>On Thu, Mar 26, 2020 at 3:21 PM John Carlson <<a href="mailto:yottzumm@gmail.com">yottzumm@gmail.com</a>> wrote:</p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'><div><p class=MsoNormal>PrototypeExpander needs unique DEFs for routes to work right, I believe.</p></div><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal>On Thu, Mar 26, 2020 at 3:17 PM John Carlson <<a href="mailto:yottzumm@gmail.com" target="_blank">yottzumm@gmail.com</a>> wrote:</p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'><div><p class=MsoNormal>Can Leonard update his blog entry based on the various threads?</p><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><a href="https://realism.com/blog/defuse-x3d-vs-dom" target="_blank">https://realism.com/blog/defuse-x3d-vs-dom</a> </p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>I think the important thing to get across is:</p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>DEFs with duplicate field value may be duplicated within a scope (VRML).</p></div><div><p class=MsoNormal>DEFs with duplicate attribute value may not be duplicated within a scope (XML, HTML).</p></div><div><p class=MsoNormal>I'm not really sure what the JSON requirements are, but someone should probably go over the working draft.</p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Thanks,</p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>John </p></div></div><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal>On Thu, Mar 26, 2020 at 2:42 PM Don Brutzman <<a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a>> wrote:</p></div></div></blockquote></div></blockquote></div><p class=MsoNormal style='margin-left:.2in'>Excellent question:<br><br>On 3/26/2020 10:49 AM, John Carlson wrote:<br>> It's important to note that this thread is mainly about DEF in VRML. Which may have different behavior than DEF in XML and JSON.   Do I have the whole story now, or is VRML dependent on XML types?<br><br>The X3D Architecture defines baseline information for model rendering/behavior/interaction, regardless of how that model is saved.<br><br>The various file encodings (ClassicVRML XML JSON Binary) and programming-language bindings (EcmaScript Java Python C/C#/C++ etc.) are expected to have equivalent expressive power to define an X3D model.  Other "non-standard" alternatives (TypeScript ObjectPascal etc.) should strive to follow the same path if consistent use is desired.<br><br>Thus conversion or even "round trip" between any of the forms is expected to include all of the necessary information in the X3D model.<br><br>Thus any time we find functional or expressive differences between ClassicVRML or XML or JSON or whatever, it is a deficiency and we should fix it.<br><br>As we continue to succeed well on this challenge, X3D models become fully portable and consistent regardless of where they come from and where they go.<br><br>Once again, with feeling: Have fun with X3D!  8)<br><br>all the best, Don<br>-- <br>Don Brutzman  Naval Postgraduate School, Code USW/Br       <a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a><br>Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA   +1.831.656.2149<br>X3D graphics, virtual worlds, navy robotics <a href="http://faculty.nps.edu/brutzman" target="_blank">http://faculty.nps.edu/brutzman</a></p><p class=MsoNormal><o:p> </o:p></p></div></body></html>