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

Roy Walmsley roy.walmsley at ntlworld.com
Mon Apr 24 07:16:49 PDT 2017


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 https://www.iso.org/directives-and-policies.html) 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.

 

Roy

 

From: x3d-public [mailto:x3d-public-bounces at web3d.org] On Behalf Of Andreas Plesch
Sent: 24 April 2017 14:39
To: Don Brutzman <brutzman at nps.edu>
Cc: X3D Graphics public mailing list <x3d-public at web3d.org>
Subject: Re: [x3d-public] [...] set_Value prefix and value_changed suffix, potential v4 issue

 

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/e8323688/attachment.html>


More information about the x3d-public mailing list