[x3d-public] NIST conformance example behaviour

[Joe D Williams]

>>> "A Script node with a field containing a USE reference to a 
>>> bindable node has the ability to bind a node directly by changing 
>>> the value of the bind field.  Setting the bind value is equivalent 
>>> to receiving a set_bind event.“

That statement is correct by shown by example.
Setting the bind value can happen by ROUTE or directOut with the same 
result.

I still think the main point is that USE in the script node is not the 
same as the usual DEF/USE where a second instance of the DEFed node is 
actually added to the scenegraph. The USE in the Script node does not 
need to create a copy. When the script runs, it directly uses the 
DEFed node for the operation.

That is why the appearance of the USE in the script doesn't affect the 
general consideration of not expect to be able to USE a bindable node. 
For a bindable node, or any other node, the USE in the script is 
different.

One comment recognized that this USE is significantly different than 
the typical DEF/USE and so the term USE in the script could use a 
different identifier in order to specify the node addressed by the 
script directOut operation. Maybe that would help, but when the 
directOut operation is understood, then it is easy to see that the 
USEd node never actually gets created and that essentially, the named 
fields in the DEFed node just gets automagically set as if Route(s) 
existed.

>>
>> 1. There is this sentence in section 7.2.2 of the specification: 
>> „The results are undefined if a multiply instanced (DEF/USE) 
>> bindable node is bound.“

In the Script, the USE does not instance any node. Fields of the 
target node are manipulated directly.
The DEFed node is read or updated directly so this conflict of a 
multiply instanced node does not exist.
An X3D tool that recognized this USE in a script as a potential 
conflict would be wrong.

As for how a directOut operates, I guess the way I described it is the 
way I learned the 'ideal' way the directOut should run. I think the 
intent of directOut is exactly to make it 'invisible' to the cascade. 
If no Route, then no cascade, unless you pick up any _changed from the 
USEd node. I think this must be an uneeded detail and so has been lost 
from the docs.

Hstorically, directOut is the most simple way to do it, but when you 
want to really keep track of stuff happening in specific frame times, 
then directOuts can get sloppy fast. Just look at the history of the 
DOM. Still, it is mostly directoOut with added ways to maintain some 
concept of order. In X3D, the script is more like a sensor node, so it 
wants Routes so we can have a nice event graph. Script directOuts can 
skip around that event graph.

Thanks and Best,
Joe

.




----- Original Message ----- 
From: "Don Brutzman" <brutzman at nps.edu>
To: "Patrick Dähne" <patrick.daehne at igd.fraunhofer.de>
Cc: "Andreas Plesch" <andreasplesch at gmail.com>; "X3D Graphics public 
mailing list" <x3d-public at web3d.org>
Sent: Wednesday, January 25, 2017 10:27 PM
Subject: Re: [x3d-public] NIST conformance example behaviour


> Sincere thanks for your follow-up note Patrick.
>
> On 1/25/2017 4:50 PM, Patrick Dähne wrote:
>> Hello Don,
>>
>>> "A Script node with a field containing a USE reference to a 
>>> bindable node has the ability to bind a node directly by changing 
>>> the value of the bind field.  Setting the bind value is equivalent 
>>> to receiving a set_bind event.“
>
> This statement was the result of 20-30 minutes careful discussion on 
> the weekly teleconference today.
>
> I should have also noted that it was refined and documented as part 
> of Mantis issue 749, which was previously submitted.  Web3D 
> Consortium Member access on the website is necessary to view these 
> issues.
>
> Mantis 0000749: 7.2.2 Bindable children nodes - Amend prose
> http://www.web3d.org/member-only/mantis/view.php?id=749
>
> It seems to me that most everything said by everyone on this topic 
> (both email and teleconference) has essentially agreed on 
> functionality: that a Script field USE node does not get processed 
> as part of the scene-graph traversal, nor does it get bound simply 
> by being referenced as an SFNode field.  We carefully discussed the 
> specification prose today to ensure that all cases were considered.
>
> Interestingly the participants (Dick Roy Joe Leonard Vince and 
> myself, maybe Nicholas was still with us) looked quite closely at 
> the exact same sentence identified by you.  We tried a few prose 
> variations along the lines of what you are suggesting as well.  We 
> decided eventually that the words there were still the best we could 
> achieve.  Perhaps your phrasing is more helpful, but functionality 
> is agreed upon at least.
>
> So, for your question below, why do we want to add this additional 
> sentence quoted at the top of this message?  Continued review of 
> paragraph 7.2.2 steps (a) through (i) describes binding behaviors on 
> the basis of events being received.  The case of a Script node with 
> a field USE reference and directOutput='true' which subsequently 
> sets the value of 'bind' field during Script invocation wasn't 
> addressed... so this extra sentence was added for clarity, to 
> explicitly note that the bind/unbind operations are equivalent for 
> event access and direct access.
>
> I hope this helps explain the additional sentence.
>
> Of note is that the in-person discussions are really helpful. 
> Interpreting the specification prose can be a tricky business!  We 
> do our best to listen to every option together and achieve concise 
> descriptions.  We also reference the email thread and every direct 
> suggestion in Mantis for future reference as well.  Also essential 
> is the presence of a good example scene with agreed-upon semantics 
> for rendering and user interaction.
>
> Since Fraunhofer is a member you are of course welcome to join.  If 
> you or anyone else wants to propose a further improvement, we will 
> be happy to schedule a good time for that.  Member connection 
> information is online, non-member invitations are not a problem for 
> these topics.
>
> http://www.web3d.org/member/teleconference-information
>
> So... lots of careful listening and due diligence.  We are further 
> paying close attention to using Mantis when performing the 
> corresponding X3D specification editing in Github.
>
> Please check out the mantis issue if you still have concerns, and 
> let's review again at a good time for you (and Andreas as well). 
> There is little value in "winning" an email debate, rather we always 
> want to achieve common ground, shared understanding and (hopefully!) 
> consensus so that all implementations can consistently handle X3D 
> content.  So these efforts are all worthwhile, especially for the 
> special semantics of bindable nodes, Script execution and DEF/USE 
> referencing.
>
> More specification issues await... but we are certainly operating at 
> a greater level of working group + community knowledge than ever 
> before.  Apparently benefits are cumulative!  8)
>
> Hope we're looking ~ acceptable now.  Further improvement always 
> welcome.  Looking forward to continuing progress together with all 
> of X3D, again thanks to all involved.
>
> v/r Don
>
>
>> Sorry, I did not want to resume that nitpicking discussion, but you 
>> are taking the wrong direction :-(
>>
>> My point is:
>>
>> 1. There is this sentence in section 7.2.2 of the specification: 
>> „The results are undefined if a multiply instanced (DEF/USE) 
>> bindable node is bound.“
>>
>> 2. In the NIST example we exactly do have that case - a bindable 
>> node (DEF nav1 NavigationInfo) that is multiply instanced - once as 
>> a child of the (implicit) root Group node, and once as a child of 
>> the Script node.
>>
>> 3. => According to the specification, the example is undefined. 
>> Q.E.D.
>>
>> I do not claim that there *actually* is a problem with the NIST 
>> example, I just say that *formally* the example is invalid because 
>> of that sentence in section 7.2.2 of the specification.
>>
>> So what is the rationale behind that sentence? That is explained in 
>> the Annotated VRML97 Reference. The browser needs to determine the 
>> transformation of the currently bound Viewpoint, Background or Fog 
>> node. The NavigationInfo node actually is a special case, because 
>> for that node the transformation of the currently bound Viewpoint 
>> is taken. Now, when you DEF/USE a bindable node (or any group node 
>> above a bindable node), you have to take care that you do not add 
>> the bindable node more than once to the transformation hierarchy, 
>> because otherwise the browser cannot decide which of the 
>> transformations to take. Adding a bindable node to the Script node 
>> does *not* add it to the transformation hierarchy (see section 
>> 4.3.5 of the specification) - that is why there is no problem in 
>> the NIST example.
>>
>> So, what to do with that awkward sentence in section 7.2.2? My 
>> recommendation would be to replace it with a sentences like this: 
>> „A bindable node may only be bound when it is part of the 
>> transformation hierarchy exactly once, otherwise the result is 
>> undefined.“ But I’m sure a native english speaker can word that 
>> much better.
>>
>> Bye,
>>
>> Patrick
>
>
> 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
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>