[x3d-public] continuing route issue with X3DJSAIL - set_Value prefixandvalue_changed suffix
yottzumm at gmail.com
yottzumm at gmail.com
Thu Apr 20 21:56:54 PDT 2017
Okay, if I remove set_ or _changed, then my code shows a unknown access type and a unknown field type. I will provide an example later.
John
Sent from Mail for Windows 10
From: yottzumm at gmail.com
Sent: Thursday, April 20, 2017 11:43 PM
To: Don Brutzman
Cc: X3D Graphics public mailing list; Roy Walmsley; Job at alexkern.de
Subject: RE: continuing route issue with X3DJSAIL - set_Value prefixandvalue_changed suffix
I don’ think that “set_” or “_changed” is the problem. I believe you handled them last time I looked at the code. My initial tests modifying my serializer say the problem still exists. More examples later.
John
Sent from Mail for Windows 10
From: Don Brutzman
Sent: Thursday, April 20, 2017 10:32 AM
To: yottzumm at gmail.com
Cc: X3D Graphics public mailing list; Roy Walmsley; Job at alexkern.de
Subject: Re: continuing route issue with X3DJSAIL - set_Value prefix andvalue_changed suffix
this is a very useful example. am thinking through various ways to allow set_ prefix and _changed suffix in ROUTE toField fromField, then realized we have a specification omission.
On 4/18/2017 9:24 PM, Don Brutzman wrote:
> John, the diagnostic is telling us what it doesn't like. It can't reconcile set_cycleTime with cycleTime.
>
> Am doing my best to produce both valid .x3d and corresponding .java so that we can, in each case,
> - decide if an .x3d scene is in error;
> - decide if X3DJSAIL API is in error, or inadequate;
> - decide if the .java program is in error; or, rarely,
> - decide if the specification is in error.
Section 4.4.2.2 Field Semantics is OK. However if we look at X3D Canonical Form:
4.2.3 X3D canonical form
http://www.web3d.org/documents/specifications/19776-3/V3.3/Part03/concepts.html#X3DCanonicalForm
rules a..o there do not include this case
It looks like they should, since the purposes of canonicalization (c14n) are to
- provide most compact and unambiguous form of an X3D scene
- provide unique form of .x3d encoding to enable XML Digital Signature for authentication and XML Encryption for privacy.
In general X3DJSAIL strives to provide X3D Canonical Form as its default output for toX3dFile() serialization.
X3DObject: toFileX3D (javadoc)
http://www.web3d.org/specifications/java/javadoc/org/web3d/x3d/jsail/Core/X3DObject.html#toFileX3D-java.lang.String-
So I plan to modify the accessor and validate() methods for ROUTEObject to omit "set_" and "_changed" prefix/suffix before checking and when saving. Most likely this will prevent other unexpected edge cases from emerging later as well.
Comments welcome. Code change and recommended specification addition to follow in near future.
> You don't have to debug stylesheet unless you want too. Whatever works, I'll keep plugging away whenever possible. Sorry but I have my hands full right now with the library and conversion stylesheet and example archives... if we can isolate bugs, and debug our respective tools accordingly, that is great.
>
> The guiding spec prose here is
>
> 4.4.2.2 Field semantics
> http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/concepts.html#Routes
>
> I believe that if a field has accessType inputOutput, then a ROUTE can refer to it as zzz or set_zzz or zzz_changed as appropriate - see following spec prose.
>
> If correct, since most fields are accessType inputOutput, then there are two allowed forms within most ROUTE fromName and toName values.
>
> ============================================================================
> 4.4.2.2 Field semantics
>
> Fields define the persistent state of nodes, and values which nodes may send or receive in the form of events. X3D supports four types of access to a node's fields:
>
> initializeOnly access, which allows content to supply an initial value for the field but does not allow subsequent changes to its value;
> inputOnly access, which means that the node may receive an event to change the value of its field, but does not allow the field's value to be read;
> outputOnly access, which means that the node may send an event when its value changes, but does not allow the field's value to be written; and
> inputOutput access, which allows full access to the field: content may supply an initial value for the field, the node may receive an event to change the value of its field, and the node may send an event when its value changes.
>
> 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. Within ISO/IEC 19775, fields with inputOutput access or inputOnly access are collectively referred to as input fields, fields with inputOutput access or outputOnly access are collectively referred to as output fields, and the events these fields receive and send are called input events and output events, respectively.
>
> The initial value of an inputOutput field is its value in the X3D file, or the default value for the node in which it is contained, if a value is not specified. When an inputOutput field receives an event it shall generate an event with the same value and timestamp. The following sources, in precedence order, shall be used to determine the initial value of the inputOutput field:
>
> the user-defined value in the instantiation (if one is specified);
> the default value for that field as specified in the node or prototype definition.
>
> The recommendations for naming initializeOnly fields, inputOutput fields, outputOnly fields, and inputOnly fields for built-in nodes are as follows:
>
> All names containing multiple words start with a lower case letter, and the first letter of all subsequent words is capitalized (e.g., addChildren), with the exception of set_ and _changed, as described below.
> It is recommended that all inputOnly fields have the prefix “set_”, with the exception of the addChildren and removeChildren fields.
> Certain inputOnly fields and outputOnly fields of type SFTime do not use the "set_" prefix or "_changed" suffix.
> It is recommended that all other outputOnly fields have the suffix “_changed” appended, with the exception of outputOnly fields of type SFBool.
> ================================================================================
>
> Have been striving to make X3DJSAIL exceptions sufficiently explanatory to enable author debugging and correction. Let's try that...
>
> And so, looking at the exception you caught below, it appears that the ROUTEObject validation output should accept either either name prior to checking type. That would be an X3DJSAIL effort.
>
> Please let me know if that diagnosis seems correct. I will look at the ROUTEObject code when time permits.
>
> I should likely also add words to tooltips to describe this allowed variance.
>
> http://www.web3d.org/x3d/content/X3dTooltips.html#ROUTE
>
> Hope this email makes sense. Step by step...
>
>
> On 4/18/2017 10:24 AM, yottzumm at gmail.com wrote:
>> Java code and X3D attached. Please provide generated Java code back which runs, so I can look at it and get my java serializer working. I will soon download X3dToJava.xslt, and play with it. I guess you want me to test it too? 😊 or instead? LOL! Not everyone wants to run a stylesheet. I’ve been doing it because I don’t have a good XML to X3D JSON converter yet ☹. Let’s break the monopoly! This was my start of one: https://github.com/coderextreme/X3DJSONLD/blob/master/Standard.js Let’s just say generating X3DJSON is hard. I was even able to generate JSON for the three-x3d-loader. The code is found here: https://github.com/coderextreme/X3DJSONLD/blob/master/Three2Serializer.js so you might base it on that. IDK, working with X3DJSON as a source seems easy enough.
>>
>> John
>>
>> $ java bubbles
>>
>> org.web3d.x3d.sai.InvalidFieldValueException: ROUTE details: FROM TourTime.cycleTime (TimeSensor.SFTime.outputOnly) TO RandomTourTime.set_cycle (Script.ERROR_UNKNOWN_FIELD_TYPE.inputOnly)
>>
>> ROUTE has source-destination type mismatch, fromField='cycleTime' source and toField='set_cycle' destination have different types.
>>
>> org.web3d.x3d.sai.InvalidFieldValueException: ROUTE details: FROM TourTime.cycleTime (TimeSensor.SFTime.outputOnly) TO RandomTourTime.set_cycle (Script.ERROR_UNKNOWN_FIELD_TYPE.inputOnly)
>>
>> ROUTE has source-destination type mismatch, fromField='cycleTime' source and toField='set_cycle' destination have different types.
>>
>> at org.web3d.x3d.jsail.Core.ROUTEObject.validate(ROUTEObject.java:721)
>>
>> at org.web3d.x3d.jsail.Core.SceneObject.validate(SceneObject.java:547)
>>
>> at org.web3d.x3d.jsail.Core.X3DObject.validate(X3DObject.java:1831)
>>
>> at org.web3d.x3d.jsail.Core.X3DObject.toFileJSON(X3DObject.java:730)
>>
>> at bubbles.main(bubbles.java:79)
>>
>> Exception in thread "main" org.web3d.x3d.sai.InvalidFieldValueException: ROUTE details: FROM TourTime.cycleTime (TimeSensor.SFTime.outputOnly) TO RandomTourTime.set_cycle (Script.ERROR_UNKNOWN_FIELD_TYPE.inputOnly)
>>
>> ROUTE has source-destination type mismatch, fromField='cycleTime' source and toField='set_cycle' destination have different types.
>>
>> at org.web3d.x3d.jsail.Core.ROUTEObject.validate(ROUTEObject.java:721)
>>
>> at org.web3d.x3d.jsail.Core.SceneObject.validate(SceneObject.java:547)
>>
>> at org.web3d.x3d.jsail.Core.X3DObject.validate(X3DObject.java:1831)
>>
>> at org.web3d.x3d.jsail.Core.X3DObject.toFileJSON(X3DObject.java:730)
>>
>> at bubbles.main(bubbles.java:79)
>>
>> John
>>
>
>
> all the best, Don
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20170421/8baa82f4/attachment-0001.html>
More information about the x3d-public
mailing list