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

[Andreas Plesch]

Hi Roy,

here is the direct link to "can":
http://www.iso.org/sites/directives/2016/part2/index.xhtml#_idTextAnchor067

So "can" does not convey a requirement, only a capability.

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.

-Andreas



On Mon, Apr 24, 2017 at 10:16 AM, Roy Walmsley <roy.walmsley at ntlworld.com>
wrote:

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



-- 
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/372de3eb/attachment-0001.html>