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

John Carlson yottzumm at gmail.com
Thu Feb 10 16:15:31 PST 2022


 No.   JSON doesn’t have syntactic comments.

You must do something like:

“-children”: [ {“#comment”: “does this” } ]

Or potentially, my preference:

“#comment”: [ “does this” ]

What do you think?   I think mine clearly distinguishes comments from
fields.   Comments become more like MFStrings.

The difference is we can’t apparently put a comment in a -children field.

Why can’t we accept either technique?

John

On Thu, Feb 10, 2022 at 5:50 PM Joseph D Williams <joedwil at earthlink.net>
wrote:

>
>    - 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 <yottzumm at gmail.com>
> *Sent: *Thursday, February 10, 2022 2:20 PM
> *To: *Joseph D Williams <joedwil at earthlink.net>
> *Cc: *X3D Graphics public mailing list <x3d-public at web3d.org>
> *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) <brutzman at nps.edu>
> *Sent: *Wednesday, February 9, 2022 9:01 PM
> *To: *John Carlson <yottzumm at gmail.com>
> *Cc: *X3D Graphics public mailing list <x3d-public at web3d.org>
> *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
> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcoderextreme%2FX3DJSONLD%2Fblob%2Fmaster%2Fsrc%2Fmain%2Fschema%2Fx3d-4.0-JSONSchema.json&data=04%7C01%7Cbrutzman%40nps.edu%7Cbd4c3b3b4b9c480a478708d9ec4a3731%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637800626508897471%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=9BFtdH4oQ3m2rgQFhZLZIykqyJx29cTQBstsYI68gUM%3D&reserved=0>
>
>
>
> 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)
> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcoderextreme%2FX3DJSONLD%2Fblob%2Fmaster%2Fsrc%2Fmain%2Fschema%2Fx3d-4.0-JSONSchema.json&data=04%7C01%7Cbrutzman%40nps.edu%7Cbd4c3b3b4b9c480a478708d9ec4a3731%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637800626508897471%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=9BFtdH4oQ3m2rgQFhZLZIykqyJx29cTQBstsYI68gUM%3D&reserved=0>
>
>
>
> (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/88250271/attachment-0001.html>


More information about the x3d-public mailing list