[x3d-public] bug report X3dToJson.xslt stylesheet. Handling of SFNode as parameter to Proto
John Carlson
yottzumm at gmail.com
Sun Apr 17 07:20:20 PDT 2016
Why wouldn’t you want to create allNodes from oneNode, so allNodes is just an array of oneNode?
Pardon my ignorance.
John
> On Apr 17, 2016, at 10:01 AM, Roy Walmsley <roy.walmsley at ntlworld.com> wrote:
>
> John,
>
> At the moment my hand crafted schema permits three properties for fieldValue:
>
> 1) @name
> 2) @value
> 3) -children
>
> There is no restriction that if there is an “@value” there must not be a “-children”.
>
> No, I can see your point if that the user declared field is an SFNode type then it ought to accept a single child. So, perhaps the property would be named “-child”.
>
> Let’s assume, for the sake of argument, that we agree to permit four properties as follows:
>
> 1) @name
> 2) @value
> 3) -child
> 4) -children
>
> It would be reasonable to make the “@name” property required, since we always need it.
>
> As for the other three, only one of the three must occur.
>
> If we have a “@value” property it must be either boolean, numeric, integer, or string, or else an array of one of these types. So perhaps for the time being it is easier to leave it as “any”.
>
> If we have “-child” then it must be an object, that is, a single node. And it can be any node. This would need a new definition, e.g. “-oneNode”
>
> If we have “-children” then it must be an array of nodes. This is my existing “-allNodes” definition.
>
> However, it may have to be done along the following lines, illustrated by modifying my current design:
>
> "fieldValue": {
> "type": "array",
> "minItems": 1,
> "items": {
> "additionalProperties": false,
> "oneOf": [
> {
> "type": "object",
> "properties": {
> "@name": {
> "type": "string"
> },
> "@value": {}
> },
> "required": [
> "@name",
> "@value"
> ],
> "additionalProperties": false
> },
> {
> "type": "object",
> "properties": {
> "@name": {
> "type": "string"
> },
> "-children": {
> "$ref": "#/definitions/-allNodes"
> }
> },
> "required": [
> "@name",
> "-children"
> ],
> "additionalProperties": false
> }
> ]
> }
> },
>
>
> Appended is a graphic representation of this.
>
> Regards,
>
> Roy
>
> From: John Carlson [mailto:yottzumm at gmail.com]
> Sent: 17 April 2016 04:09
> To: Don Brutzman; Roy Walmsley
> Cc: X3D Graphics public mailing list
> Subject: Re: bug report X3dToJson.xslt stylesheet. Handling of SFNode as parameter to Proto
>
> 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 <mailto: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 <mailto: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 <mailto: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 <http://faculty.nps.edu/brutzman>
>>> <rubikOnFire.json>
>>>
>>
>>
>
>
> <JSON Schema fieldValue definition.png>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20160417/80a127c5/attachment-0001.html>
More information about the x3d-public
mailing list