[x3d-public] X3D JSON Schema - validating comments inside a USEnode

Joseph D Williams joedwil at earthlink.net
Thu Feb 10 15:50:24 PST 2022


➢ have  one technique for adding #comment in JSON.  

Right, json same as classic: 
…
4 5 6  # does this
… 
 I general, any # stuff ends line. This is fine for classic and json? 

For xml, should be able to put something maybe <! … />  in attr between sf in an mF to end line. 
I know that looks hard to do because how do you tell the xml attr that it is there, embedded in the attr data that is expected to be nice and clean, but it would be worth it to accommodate more convenient comments for sfs in mfs provided by classic and json forms. 
Thanks and Best, 
Joe


From: John Carlson
Sent: Thursday, February 10, 2022 2:20 PM
To: Joseph D Williams
Cc: X3D Graphics public mailing list
Subject: Re: [x3d-public] X3D JSON Schema - validating comments inside a USEnode

Good points, Joe.  This particular issue was trying to limit the fields that go along with a @USE field in JSON. One camp was thinking there should only be a @class field along with @USE, and another was saying we also needed    #comment with a -children field.   We may choose another way of adding comments, I’m not opposed to that, and I favor that, if we can get everyone to agree.  Otherwise we only have  one technique for adding #comment in JSON.   That may be limiting us.

I’ve pretty much always advocated a more XML-like approach for JSON, but there was a desire to make JSON look like VRML, I guess.

I’m hoping we can discover some kind of sharing mechanism in JSON schema to reduce heavy duplication.

Anyway, here we are.

John

On Thu, Feb 10, 2022 at 3:36 PM Joseph D Williams <joedwil at earthlink.net> wrote:
• In general we want to be able to “round trip” convert between any of the X3D encodings without loss of X3D scene information, including comments.
 
This really shows when, like I did for the kicker, it helped to set a comment to identify each coordinate point of the skin shape. The objective was to keep track of point index in order of appearance according to names assigned to standard surface features. At the first transcoding from classic to xml those comments were transported into a big comment at the end of the xml. Then when back to classic, of course those comments remained basically disassociated from the individual point that was intended to be documented. 
I sort of knew what was going to happen because when the mf points field becomes an attr, it don’t like to find embedded comments. The xml mf field only contains sfs to make mfs and needs comment childs or meta childs, while the classic mf can have a comment for each individual sf in the mf list. So I didn’t compensate using a different style of comments and so the reference became basically useless unless the transform rules are known. 
 
What has changed since we chose our sf and mf xmlization path? Well for one thing it ought to be a lot easier to just say Hey if we wanna put comments for each sf in the mf list, then OK Thus it will be ok to comment an sf in an mf with end of line comment for the mf numeric lists.  
 
Same with the json/gltF encodings, embedded comment to document an sf in the mf should be ok, and directly transcodable from xml or json or gltf to classic.  
 
Thanks, 
Joe
 
From: Brutzman, Donald (Don) (CIV)
Sent: Wednesday, February 9, 2022 9:01 PM
To: John Carlson
Cc: X3D Graphics public mailing list
Subject: Re: [x3d-public] X3D JSON Schema - validating comments inside a USEnode
 
[Adjusted subject line to match topic] Hello again John, thanks for further detail.
 
The following is valid XML:
 
            <Shape USE='Torus'>
              <!-- Knot -->
            </Shape>
 
As is the following VRML fragment, if found in the right place:
 
       USE Torus # Knot
 
Certainly the most common place to find comments in practice will be as children within a grouping node, or at the top of a scene.  So it is clearly an important use case to support.
 
In general we want to be able to “round trip” convert between any of the X3D encodings without loss of X3D scene information, including comments.
 
So if your JSON schema is not validating such comments, may I recommend that you add such support.  Good luck!
 
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 https:// faculty.nps.edu/brutzman
 
From: x3d-public <x3d-public-bounces at web3d.org> On Behalf Of John Carlson
Sent: Wednesday, February 9, 2022 8:02 PM
To: X3D Graphics public mailing list <x3d-public at web3d.org>
Subject: Re: [x3d-public] X3D JSON Schema updated for axis++ defaults (regression failure)
 
Report on JSON file generated by X3dToJson.xslt, download from  https://www.web3d.org/x3d/content/examples/Basic/StudentProjects/TrebuchetIndex.html
 
Note that the JSON linked file (on the above linked page) is essentially identical to the  February 9th version, except for the date.
 
X3dToJson.xslt needs to be updated to not produce comments inside -children fields at the same level as @USE field.  There should be NO -children fields at the same level as @USE in X3DJSON
 
I believe this is the JSON in question.  Note @USE and -children at the same level.
==
 { "Shape":
                                    {
                                      "@USE":"Torus",
                                      "-children":[
                                        {
                                          "#comment":"Knot"
                                        }
                                      ]
                                    }
==
This appears to be the problematic XML, but double check me please (there are two Knot comments).
            <Shape USE='Torus'>
              <!-- Knot -->
            </Shape>
 
==
 
Please suggest an alternate JSON encoding of this XML

Updated JSON schema (with Bounded Object updates) available at normal locations (see messages included).
 
Thanks!
 
John
 
$ node x3dvalidate.js Trebuchet.json
Can only validate version 4.0 presently. Switching version to 4.0.
Loading schema
Parsing schema
Adding schema
Schema 4.0 added
Schema 4.0 compiled
================================================================================
File: Trebuchet.json
Error reading Trebuchet.json
 keyword: required
 instancePath: /X3D/Scene/-children/8/Transform
 message: must have required property @USE
 params: {"missingProperty":"@USE"}
 file: Trebuchet.json
 version: 3.0

 keyword: required
 instancePath: /X3D/Scene/-children/8/Transform/-children/8/Transform
 message: must have required property @USE
 params: {"missingProperty":"@USE"}
 file: Trebuchet.json
 version: 3.0

 keyword: required
 instancePath: /X3D/Scene/-children/8/Transform/-children/8/Transform/-children/4/Transform
 message: must have required property @USE
 params: {"missingProperty":"@USE"}
 file: Trebuchet.json
 version: 3.0

 keyword: required
 instancePath: /X3D/Scene/-children/8/Transform/-children/8/Transform/-children/4/Transform/-children/0/Transform
 message: must have required property @USE
 params: {"missingProperty":"@USE"}
 file: Trebuchet.json
 version: 3.0

 keyword: additionalProperties
 instancePath: /X3D/Scene/-children/8/Transform/-children/8/Transform/-children/4/Transform/-children/0/Transform/-child
ren/0/Shape
 message: must NOT have additional properties
 params: {"additionalProperty":"-children"}
 file: Trebuchet.json
 version: 3.0

 keyword: additionalProperties
 instancePath: /X3D/Scene/-children/8/Transform/-children/8/Transform/-children/4/Transform/-children/0/Transform/-child
ren/0/Shape
 message: must NOT have additional properties
 params: {"additionalProperty":"@USE"}
 file: Trebuchet.json
 version: 3.0

 keyword: oneOf
 instancePath: /X3D/Scene/-children/8/Transform/-children/8/Transform/-children/4/Transform/-children/0/Transform/-child
ren/0/Shape
 message: must match exactly one schema in "oneOf"
 params: {"passingSchemas":null}
 file: Trebuchet.json
 version: 3.0

 keyword: oneOf
 instancePath: /X3D/Scene/-children/8/Transform/-children/8/Transform/-children/4/Transform/-children/0/Transform
 message: must match exactly one schema in "oneOf"
 params: {"passingSchemas":null}
 file: Trebuchet.json
 version: 3.0

 keyword: oneOf
 instancePath: /X3D/Scene/-children/8/Transform/-children/8/Transform/-children/4/Transform
 message: must match exactly one schema in "oneOf"
 params: {"passingSchemas":null}
 file: Trebuchet.json
 version: 3.0

 keyword: oneOf
 instancePath: /X3D/Scene/-children/8/Transform/-children/8/Transform
 message: must match exactly one schema in "oneOf"
 params: {"passingSchemas":null}
 file: Trebuchet.json
 version: 3.0

 keyword: oneOf
 instancePath: /X3D/Scene/-children/8/Transform
 message: must match exactly one schema in "oneOf"
 params: {"passingSchemas":null}
 file: Trebuchet.json
 version: 3.0
 
On Mon, Feb 7, 2022 at 11:12 PM John Carlson <yottzumm at gmail.com> wrote:
New fetchable X3D V4.0 JSON Schema fetchable from:
 
https://github.com/coderextreme/X3DJSONLD/blob/master/src/main/schema/x3d-4.0-JSONSchema.json
 
Includes changes to title...word ordering and date time (now being the time generated.
 
On Thu, Jan 27, 2022 at 2:55 PM John Carlson <yottzumm at gmail.com> wrote:
You may now grab new versions of X3D JSON schema:
 
X3DJSONLD/x3d-4.0-JSONSchema.json at master · coderextreme/X3DJSONLD (github.com)
 
(Includes Navigation.type update to JSON string instead of JSON array)
 
Thanks for your support!
John
 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20220210/d85685aa/attachment.html>


More information about the x3d-public mailing list