[x3d-public] bug report X3dToJson.xslt stylesheet. Handling of SFNode as parameter to Proto

John Carlson yottzumm at gmail.com
Sat Apr 16 20:08:34 PDT 2016


Well the stylesheet isn’t fixed yet.  Here’s the diff to the stylesheet output that makes my prototype expander code work:

diff --git a/rubikOnFire.json b/rubikOnFire.json
index 7242909..c8120f3 100644
--- a/rubikOnFire.json
+++ b/rubikOnFire.json
@@ -397,13 +397,12 @@
                 },
                 {
                   "@name":"myShape",
-                  "-children":[
+                  "-children":
                     { "Box":
                       {
                         "@size":[1,1,1]
                       }
                     }
-                  ]
                 }
               ]
             }


Submitted for your consideration.  I can always had modify code (and so can everyone else???)  -value doesn’t work for me, because it doesn’t pass schema. Using an object doesn’t work in schema.   So I will look at that next.

John
> On Apr 16, 2016, at 10:42 PM, John Carlson <yottzumm at gmail.com> wrote:
> 
> I take that back.  Here’s what I’d like to do…I’d like -children to support both an object (SFNode) and an array (MFNode), so syntax like this
> is acceptable:
> 
>          { "ProtoInstance":
>             {
>               "@name":"twentyseven",
>               "fieldValue": [
>                 {
>                   "@name":"ttranslation",
>                   "@value":[0,0,0]
>                 },
>                 {
>                   "@name":"myShape",
>                   "-children": {
>                     "Box": {
>                       "@size":[1,1,1]
>                     }
>                   }
>                 }
>               ]
>             }
>           }
> 
> 
> Thus, if you have an SFNode, it will will generate syntax like the above for -children, and if you have an MFNode, the stylesheet will generate an array for -children.  And then the schema will either accept an array or an object.
> 
> Is this possible?  I will test to see if the stylesheet is already fixed.
> 
> John
>> On Apr 16, 2016, at 10:28 PM, John Carlson <yottzumm at gmail.com <mailto:yottzumm at gmail.com>> wrote:
>> 
>> I have verified that using -children solves my problem (at least with schema!).
>> 
>> Thanks,
>> 
>> John
>>> On Apr 3, 2016, at 12:26 PM, Don Brutzman <brutzman at nps.edu <mailto:brutzman at nps.edu>> wrote:
>>> 
>>> Apologies for delayed reply.
>>> 
>>> Here is the rule that was decided as most straightforward and consistent (currently last bullet under Completed Work):
>>> 
>>> http://www.web3d.org/x3d/stylesheets/X3dToJson.html#Issues <http://www.web3d.org/x3d/stylesheets/X3dToJson.html#Issues>
>>> 
>>> * field and fieldValue statements containing SFNode/MFNode content use the -children key.
>>> 
>>> Your scene passes all X3D Validator tests (good job there) and I think the relevant excerpts that you are referring to are
>>> 
>>> =================================================================
>>> ...
>>> <ProtoDeclare name='twentyseven'>
>>> <ProtoInterface>
>>> 	<field accessType='inputOutput' name='ttranslation' type='SFVec3f' value='0.0 0.0 0.0'/>
>>> 	<field accessType='inputOutput' name='myShape' type='SFNode'>
>>> 	  <Sphere/>
>>> 	</field>
>>> </ProtoInterface>
>>> <ProtoBody>
>>> 	<Transform translation='0 0 0'>
>>> 	  <IS>
>>> 		<connect nodeField='translation' protoField='ttranslation'/>
>>> 	  </IS>
>>> 	  <ProtoInstance name='nine'>
>>> 		<fieldValue name='ztranslation' value='0 0 0'/>
>>> 		<IS>
>>> 		  <connect nodeField='myShape' protoField='myShape'/>
>>> 		</IS>
>>> 	  </ProtoInstance>
>>> 	  <ProtoInstance name='nine'>
>>> 		<fieldValue name='ztranslation' value='0 0 2'/>
>>> 		<IS>
>>> 		  <connect nodeField='myShape' protoField='myShape'/>
>>> 		</IS>
>>> 	  </ProtoInstance>
>>> 	  <ProtoInstance name='nine'>
>>> 		<fieldValue name='ztranslation' value='0 0 -2'/>
>>> 		<IS>
>>> 		  <connect nodeField='myShape' protoField='myShape'/>
>>> 		</IS>
>>> 	  </ProtoInstance>
>>> 	</Transform>
>>> </ProtoBody>
>>> </ProtoDeclare>
>>> <ProtoInstance name='twentyseven'>
>>> <fieldValue name='ttranslation' value='0 0 0'/>
>>> <fieldValue name='myShape'>
>>> 	<Box size='1 1 1'/>
>>> </fieldValue>
>>> </ProtoInstance>
>>> =================================================================
>>> 
>>> So the corresponding conversion of the ProtoInstance to JSON would be
>>> 
>>> { "ProtoInstance":
>>> {
>>> 	"@name":"twentyseven",
>>> 	"fieldValue": [
>>> 	  {
>>> 		"@name":"ttranslation",
>>> 		"@value":[0,0,0]
>>> 	  },
>>> 	  {
>>> 		"@name":"myShape",
>>> 		"-children":[
>>> 		  { "Box":
>>> 			{
>>> 			  "@size":[1,1,1]
>>> 			}
>>> 		  }
>>> 		]
>>> 	  }
>>> 	]
>>> }
>>> }
>>> 
>>> This JSON excerpt above matches the ProtoInstance in "rubikOnFireFlawed.json" file you sent a week ago.
>>> 
>>> Full result from X3dToJson.xslt stylesheet attached, passes jslint and also passes Roy's X3D JSON Schema validation.
>>> 
>>> Incidentally, nested prototypes are certainly allowed by X3D Specification but the great majority of my testing to date has not been testing nesting.
>>> 
>>> 
>>> On 3/25/2016 11:35 PM, John Carlson wrote:
>>>> So it actually caught it after my PrototypeExpander ran on it.  So there may be a bug with how my PrototypeExpander handles -children which are SFNodes (actually they are MFNodes (arrays) in the JSON code, so I think the JSON is wrong).  You guys may have discussed this, or something like it, and I was ignorant at the time.
>>>> 
>>>> John
>>>>> On Mar 26, 2016, at 2:28 AM, John Carlson <yottzumm at gmail.com> wrote:
>>>>> 
>>>>> If you pass an SFNode to a Proto, it is treated as an MFNode and given -children, and not -value or -child.  This can create -geometry nodes which are arrays instead of objects.  Here are an X3D example, the converted JSON, and how the JSON should appear (hand edited).  I did not pick -value or -child because I forgot what we chose.  I could probably fix this another way, but i think -children is misleading when it’s an SFNode.<rubikOnFire.json><rubikOnFire.x3d><rubikOnFireFixed.json>You may use my X3D file in your X3D resources examples if you wish.  rubikOnFire.json  does not pass schema. If there’s a problem with my X3D file, then we should fix QA, because it passed the latest X3D-Edit tests. (Perhaps there should be a warning?).  If there is a problem with my X3D file, then JSON should not be produced.
>>>>> 
>>>>> So take your pick, fix the stylesheet, or find an error in my X3D file.   Good luck with both.
>>>>> 
>>>>> There’s likely more bugs to report.  This is just the first one.  Good catch Roy!
>>>>> 
>>>>> Thanks,
>>>>> 
>>>>> John
>>> 
>>> 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
>>> <rubikOnFire.json>
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20160416/62d821c2/attachment-0001.html>


More information about the x3d-public mailing list