<div dir="ltr"><div>First, quick testing of <a href="http://www.web3d.org/x3d/content/examples/ConformanceNist/Interpolators/PositionInterpolator/simpleIndex.html">http://www.web3d.org/x3d/content/examples/ConformanceNist/Interpolators/PositionInterpolator/simpleIndex.html</a> with cobweb and x3dom (using <a href="http://andreasplesch.github.io/Library/Viewer/x3dweb.html">http://andreasplesch.github.io/Library/Viewer/x3dweb.html</a>) reveals that both require "set_" and "_changed".</div><div><br></div><div>However, I do not see this requirement in the spec.</div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><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.<br>
<br></blockquote><div><br></div><div>Agreed.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
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_fract<wbr>ion). <br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<a href="http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/time.html#TimeSensor" rel="noreferrer" target="_blank">http://www.web3d.org/documents<wbr>/specifications/19775-1/V3.3/<wbr>Part01/components/time.html#Ti<wbr>meSensor</a><br>
<br>
<a href="http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/interp.html#PositionInterpolator" rel="noreferrer" target="_blank">http://www.web3d.org/documents<wbr>/specifications/19775-1/V3.3/<wbr>Part01/components/interp.html#<wbr>PositionInterpolator</a></blockquote><div><br></div><div><br></div><div>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).</div><div><br></div><div>The question is if in the phrase</div><div><br></div><div><div>"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."</div></div><div><br></div><div>"can" is interpreted to mean "may, but does not need to" or as "needs to .., if it is to be treated as"</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<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_fract<wbr>ion 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.<br>
<br></blockquote><div><br></div><div>Yes, consistency would be great. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
hmm hmm hmm... Any other observations for this list of considerations?<br>
<br></blockquote><div><br></div><div>Here is how I do output event passing from x3d to dom in cobweb_dom:</div><div><br></div><div><a href="https://github.com/andreasplesch/cobweb_dom/blob/master/release/cobweb_dom.0.8.js#L161">https://github.com/andreasplesch/cobweb_dom/blob/master/release/cobweb_dom.0.8.js#L161</a><br></div><div><br></div><div>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">http://www.web3d.org/documents/specifications/19777-1/V3.3/Part1/functions.html#t-FieldFunctions</a></div><div><br></div><div>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.</div><div><br></div></div><div>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].</div><div><br></div><div>-Andreas</div>-- <br><div class="gmail_signature">Andreas Plesch<br>39 Barbara Rd.<br>Waltham, MA 02453</div>
</div></div>