[x3d-public] bug report X3dToJson.xslt stylesheet. Handling of SFNode as parameter to Proto
John Carlson
yottzumm at gmail.com
Sat Apr 16 19:42:16 PDT 2016
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> 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> 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
>>
>> * 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/62c3f838/attachment-0001.html>
More information about the x3d-public
mailing list