<div dir="ltr">Hi Roy,<div><br></div><div>here is the direct link to "can":</div><div><a href="http://www.iso.org/sites/directives/2016/part2/index.xhtml#_idTextAnchor067">http://www.iso.org/sites/directives/2016/part2/index.xhtml#_idTextAnchor067</a><br></div><div><br></div><div>So "can" does not convey a requirement, only a capability.</div><div><br></div><div>I also noticed that "may not" does not appear in the ISO directive. I wonder if it makes sense to just search for "may not" in spec. as a whole.</div><div><br></div><div>-Andreas</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Apr 24, 2017 at 10:16 AM, Roy Walmsley <span dir="ltr"><<a href="mailto:roy.walmsley@ntlworld.com" target="_blank">roy.walmsley@ntlworld.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-GB" link="blue" vlink="purple"><div class="m_7306772371526703742WordSection1"><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Andreas, your comments about the unclear use of “can” are symptomatic of the fact that the text in the standards needs improvements in the use of verbal forms. The ISO/IEC Directives Part 2 (available at <a href="https://www.iso.org/directives-and-policies.html" target="_blank">https://www.iso.org/<wbr>directives-and-policies.html</a>) now has very clear guidelines on this topic. At 7 Verbal forms for expressions of provisions, the use of “shall”, “shall not”, “should”, “should not”, “may”, “need not”, “can”, “cannot”, and “must” are all very clearly described. As part of the updating to version 4.0 process I intend to ensure that the text of all the standards is updated to conform to these requirements. This should remove such ambiguities.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Roy<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><u></u> <u></u></span></p><p class="MsoNormal"><b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif"> x3d-public [mailto:<a href="mailto:x3d-public-bounces@web3d.org" target="_blank">x3d-public-bounces@<wbr>web3d.org</a>] <b>On Behalf Of </b>Andreas Plesch<br><b>Sent:</b> 24 April 2017 14:39<br><b>To:</b> Don Brutzman <<a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a>><br><b>Cc:</b> X3D Graphics public mailing list <<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a>><br><b>Subject:</b> Re: [x3d-public] [...] set_Value prefix and value_changed suffix, potential v4 issue<u></u><u></u></span></p><p class="MsoNormal"><u></u> <u></u></p><div><div><p class="MsoNormal">First, quick testing of <a href="http://www.web3d.org/x3d/content/examples/ConformanceNist/Interpolators/PositionInterpolator/simpleIndex.html" target="_blank">http://www.web3d.org/x3d/<wbr>content/examples/<wbr>ConformanceNist/Interpolators/<wbr>PositionInterpolator/<wbr>simpleIndex.html</a> with cobweb and x3dom (using <a href="http://andreasplesch.github.io/Library/Viewer/x3dweb.html" target="_blank">http://andreasplesch.<wbr>github.io/Library/Viewer/<wbr>x3dweb.html</a>) reveals that both require "set_" and "_changed".<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">However, I do not see this requirement in the spec.<u></u><u></u></p></div><div><div><blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm"><p class="MsoNormal" style="margin-bottom:12.0pt"><br>FWIW am not trying to create new requirements or restrictions...  just trying to read things closely.  Key excerpt:<br><br>"An inputOutput field can receive events like an inputOnly field, can generate events like an outputOnly field, and can be stored in X3D files like an initializeOnly field. An inputOutput field named zzz can be referred to as 'set_zzz' and treated as an inputOnly, and can be referred to as 'zzz_changed' and treated as an outputOnly field."<br><br>Each sentence begins with "An inputOutput field" so that seems precise.  No other section found about optional nature of set_ or _changed.<u></u><u></u></p></blockquote><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">Agreed.<u></u><u></u></p></div><div><p class="MsoNormal"> <u></u><u></u></p></div><blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm"><p class="MsoNormal">So for example, am not finding any specification prose that would permit routing from a TimeSensor.fraction (it is defined as TimeSensor.fraction_changed) or into a PositionInterpolator.fraction (it is defined as PositionInterpolator.set_<wbr>fraction). <u></u><u></u></p></blockquote><blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm"><p class="MsoNormal"><a href="http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/time.html#TimeSensor" target="_blank">http://www.web3d.org/<wbr>documents/specifications/<wbr>19775-1/V3.3/Part01/<wbr>components/time.html#<wbr>TimeSensor</a><br><br><a href="http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/interp.html#PositionInterpolator" target="_blank">http://www.web3d.org/<wbr>documents/specifications/<wbr>19775-1/V3.3/Part01/<wbr>components/interp.html#<wbr>PositionInterpolator</a><u></u><u></u></p></blockquote><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">But these are input_only and output_only fields, not inputoutput fields. Here is the spec. follows (satisfyingly) its own recommendation from 4.4.2.2 Field Semantics, items h) and j).<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">The question is if in the phrase<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><div><p class="MsoNormal">"An inputOutput field can receive events like an inputOnly field, can generate events like an outputOnly field, and can be stored in X3D files like an initializeOnly field. An inputOutput field named zzz can be referred to as 'set_zzz' and treated as an inputOnly, and can be referred to as 'zzz_changed' and treated as an outputOnly field."<u></u><u></u></p></div></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">"can" is interpreted to mean "may, but does not need to" or as "needs to .., if it is to be treated as"<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">Although, to me, the common sense interpretation would be the former (especially since h) and j) only recommended but do not require naming fields with adornments), it looks like the consensus is actually the latter, probably to align inputoutput field naming in routes with input/output_only field naming.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">The next question is if there are actually situation where it is necessary to disambiguate the role of the inputoutput field because its role not uniquely defined. In Routes, for example, it does not seem to be necessary because from fields are always output and to fields always input.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm"><p class="MsoNormal" style="margin-bottom:12.0pt"><br>Anyway that is the basis for the prior analysis.  Now let's spin 180 and look forwards:<br><br>Given that apparent v3.3 specification strictness, it seems like this approach needs to be relaxed and better defined to enable X3D v4 compatibility with DOM.<br><br>At a minimum v4.4 functionality should ensure that<br><br>a. treatment of set_ and _changed is identical for all accessType fields (obscure disparities can lead to erroneous code and content for no good reason).<br><br>b. consider whether set_ and _changed can be optional/disposable so that all field names are unambiguous, e.g. TimeSensor.fraction and PositionSensor.value respectively match TimeSensor.fraction_changed and PositionInterpolator.set_<wbr>fraction references.<br><br>c. Coherent naming is essential if we are going to have meaningful event passing at both DOM level and within a scene as well.<u></u><u></u></p></blockquote><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">Yes, consistency would be great. <u></u><u></u></p></div><div><p class="MsoNormal"> <u></u><u></u></p></div><blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm"><p class="MsoNormal" style="margin-bottom:12.0pt">hmm hmm hmm... Any other observations for this list of considerations?<u></u><u></u></p></blockquote><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">Here is how I do output event passing from x3d to dom in cobweb_dom:<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal"><a href="https://github.com/andreasplesch/cobweb_dom/blob/master/release/cobweb_dom.0.8.js#L161" target="_blank">https://github.com/<wbr>andreasplesch/cobweb_dom/blob/<wbr>master/release/cobweb_dom.0.8.<wbr>js#L161</a><u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">This relies on the addfieldcallback SAI function being available in a browser, defined here <a href="http://www.web3d.org/documents/specifications/19777-1/V3.3/Part1/functions.html#t-FieldFunctions" target="_blank">http://www.web3d.org/<wbr>documents/specifications/<wbr>19777-1/V3.3/Part1/functions.<wbr>html#t-FieldFunctions</a><u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">I generate a DOM event for each x3d output event but prefix it with 'x3d_' as an event namespace. The DOM event is dispatched from the x3d node which generated the event which means when a DOM listen handler receives the event, the x3d node will be defined as the event target.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div></div><div><p class="MsoNormal">In cobweb_dom x3d input events are generated by mutating an x3d element (in the dom). [As an implementation detail, I use an addEvent() SAI type, but internal cobweb function, rather than the SAI x3dNode[fieldName_as_property] functionality because I think cobweb allows fields as properties only in x3d scripts].<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">-Andreas<u></u><u></u></p></div><p class="MsoNormal">-- <u></u><u></u></p><div><p class="MsoNormal">Andreas Plesch<br>39 Barbara Rd.<br>Waltham, MA 02453<u></u><u></u></p></div></div></div></div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Andreas Plesch<br>39 Barbara Rd.<br>Waltham, MA 02453</div>
</div>