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

[Don Brutzman]

On 4/23/2017 8:06 PM, Andreas Plesch wrote:
> 
>     Date: Sun, 23 Apr 2017 19:44:18 -0700
>     From: Don Brutzman <brutzman at nps.edu <mailto:brutzman at nps.edu>>
> 
>     John, as it turns out, the set_ prefix and _changed suffix are only optional when connecting to accessType inputOutput fields.  They are required for a large number of output_only and inputOnly fields (respectively).
> 
> 
>  From what I can see in
> http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/concepts.html#FieldSemantics <http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/concepts.html#FieldSemantics>
> 
> the set_ and _changed adornments are _recommended_ , presumably for reasons of better readability. Since these did not seem to be required, browser makers had to allow for both options, pure and adorned. Can you clarify your argument for a strict requirement ?
> 
> Andreas

Thanks Andreas for scrutinizing this, it is important.

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.

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

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.

hmm hmm hmm... Any other observations for this list of considerations?

all the best, Don
-- 
Don Brutzman  Naval Postgraduate School, Code USW/Br       brutzman at nps.edu
Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA   +1.831.656.2149
X3D graphics, virtual worlds, navy robotics http://faculty.nps.edu/brutzman