[x3d-public] [...] set_Value prefix and value_changed suffix, potential v4 issue

[Andreas Plesch]

First, quick testing of
http://www.web3d.org/x3d/content/examples/ConformanceNist/Interpolators/PositionInterpolator/simpleIndex.html
with cobweb and x3dom (using
http://andreasplesch.github.io/Library/Viewer/x3dweb.html) reveals that
both require "set_" and "_changed".

However, I do not see this requirement in the spec.

>
> FWIW am not trying to create new requirements or restrictions...  just
> trying to read things closely.  Key excerpt:
>
> "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."
>
> Each sentence begins with "An inputOutput field" so that seems precise.
> No other section found about optional nature of set_ or _changed.
>
>
Agreed.


> 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_fraction).
>
http://www.web3d.org/documents/specifications/19775-1/V3.3/
> Part01/components/time.html#TimeSensor
>
> http://www.web3d.org/documents/specifications/19775-1/V3.3/
> Part01/components/interp.html#PositionInterpolator



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).

The question is if in the phrase

"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."

"can" is interpreted to mean "may, but does not need to" or as "needs to
.., if it is to be treated as"

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.

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.


> Anyway that is the basis for the prior analysis.  Now let's spin 180 and
> look forwards:
>
> 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.
>
> At a minimum v4.4 functionality should ensure that
>
> 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).
>
> 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_fraction references.
>
> c. Coherent naming is essential if we are going to have meaningful event
> passing at both DOM level and within a scene as well.
>
>
Yes, consistency would be great.


> hmm hmm hmm... Any other observations for this list of considerations?
>
>
Here is how I do output event passing from x3d to dom in cobweb_dom:

https://github.com/andreasplesch/cobweb_dom/blob/master/release/cobweb_dom.0.8.js#L161

This relies on the addfieldcallback SAI function being available in a
browser, defined here
http://www.web3d.org/documents/specifications/19777-1/V3.3/Part1/functions.html#t-FieldFunctions

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.

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].

-Andreas
-- 
Andreas Plesch
39 Barbara Rd.
Waltham, MA 02453
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20170424/3ae59dc8/attachment.html>