[x3d-public] "deep dive" on containerField and value fields for Metadata* node examples
Michalis Kamburelis
michalis.kambi at gmail.com
Mon Jul 17 18:26:47 PDT 2023
John,
It seems you confuse a bit how containerField works. There's no such
thing as "containerField underneath...". The "default containerField"
is determined by the node in question (the child node, that we need to
decide in which SFNode / MFNode of parent to place). The "default
containerField" is *not* determined by the context (like the
containing XML element).
That is what X3D XML encoding spec says, that's why it contains a long
table of nodes that clarifies default containerField for each node:
https://www.web3d.org/documents/specifications/19776-1/V3.3/Part01/EncodingOfNodes.html#MetadataBoolean
( These are not specified in "X3D Abstract : Node Definitions", since
containerField is a specific feature only necessary in the XML
encoding. )
Reading Don message (point 8), I see that containerField of
X3DMetadataNode changed from "metadata" to "value". The example from
Don, also in point 8, showing difference between X3D 3 and 4, confirms
this.
Regards,
Michalis
wt., 18 lip 2023 o 02:39 John Carlson <yottzumm at gmail.com> napisał(a):
>
> Michalis, my understanding is that the default containerField for metadata underneath a MetadataSet is "value", and underneath a non-metadata node the default containerField is "metadata". Shape does not have a field named "value", and thus a direct child of shape cannot have a default containerField with value "value". That's where the trickiness lies, and the issue with the X3dToJson.xslt script (which I haven't checked recently).
>
> That is my main point.
>
> I'm going to continue to work on a XML to JSON replacement for web browsers, it looks like Holger has something. SaxonJS is inscrutable.
>
> If someone can get SaxonJS to work on a web browser, let me know!
>
> John
>
> On Mon, Jul 17, 2023 at 4:55 PM Michalis Kamburelis <michalis.kambi at gmail.com> wrote:
>>
>> Don,
>>
>> Sorry for reacting to this thread with~ 2-week delay.
>>
>> From your mail, I see that the default containerField for MetadataXxx
>> nodes (X3DMetadataNode descendants) changed in X3D.
>>
>> It was "metadata" in X3D 3.x (and this is what Castle Game Engine /
>> view3dscene uses now), but it changed to be "value" since X3D 4.0, if
>> I understand you right.
>>
>> I'll see how to account for it in CGE. It will be a bit tricky --
>> although we always know exact X3D version when reading/writing, we
>> usually avoid making significant behavior changes just because of X3D
>> version change (because users don't always pay attention to the exact
>> X3D version they use). In this case, we'll have to.
>>
>> - Can you point me to the X3D 4 XML Encoding spec? On
>> https://www.web3d.org/standards I see for X3D 4 only "X3D Abstract :
>> Node Definitions", and the "X3D Encoding : XML" is only available for
>> X3D 3.3.
>>
>> - Is there a summary document / diff containing these changes? Not
>> only to "X3D Abstract : Node Definitions" but also to "X3D Encoding :
>> XML" for X3D 4.0?
>>
>> Thanks,
>> Michalis
>>
>> pon., 3 lip 2023 o 09:51 John Carlson <yottzumm at gmail.com> napisał(a):
>> >
>> > When I say container field (in JSON),I mean something like "-value" ... (not that I'm advocating for this, but it is used for children of Metadata* nodes), not @value. Let's be really clear on that. Let's come up with a term for "-metadata" "-geometry", "-appearance", etc., so I can be perfectly clear. I prefer "{metadata, geometry, appearance} container field", but others may have another choice. I think Roy had a term for it, but I forget. I realize one cannot use -value as a field of Shape. That's what I'm advocating against in HelloWorldProgramOutput.json. Just look at this incorrect example:
>> >
>> > https://sourceforge.net/p/x3d/code/HEAD/tree/www.web3d.org/x3d/stylesheets/java/examples/HelloWorldProgramOutput.json
>> >
>> > Search for a few examples for -value (use CTRL-f to search), especially under the Shape property value.
>> >
>> > I realize I may have a different style of communication.
>> >
>> > John
>> >
>> > On Sun, Jul 2, 2023 at 6:32 PM Brutzman, Donald (Don) (CIV) <brutzman at nps.edu> wrote:
>> >>
>> >> John, there are several issues with your mail that can be confusing. Am trying here to untangle them. You likely understand all this, but email can be tricky to follow.
>> >>
>> >>
>> >>
>> >> Summary: here is a "deep dive" on containerField and value fields for Metadata* node examples.
>> >>
>> >>
>> >>
>> >> First, the url that you have is not current. The latest specification (International Standard proof version) url follows.
>> >>
>> >>
>> >>
>> >> Please use the latest url, and stop using other urls.
>> >>
>> >>
>> >>
>> >> X3D Architecture reference:
>> >>
>> >>
>> >>
>> >> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-IS.proof/Part01/Architecture.html
>> >>
>> >>
>> >>
>> >> Next, when you look at Shape node, there is no “value” field. There are fields defined for appearance, bboxDisplay, castShadow, geometry, metadata, visible, bboxCenter and bboxSize.
>> >>
>> >>
>> >>
>> >> X3D Architecture reference:
>> >>
>> >>
>> >>
>> >> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-IS.proof/Part01/components/shape.html#Shape
>> >>
>> >>
>> >>
>> >> Shape : X3DShapeNode {
>> >>
>> >> SFNode [in,out] appearance NULL [X3DAppearanceNode]
>> >>
>> >> SFBool [in,out] bboxDisplay FALSE
>> >>
>> >> SFBool [in,out] castShadow TRUE
>> >>
>> >> SFNode [in,out] geometry NULL [X3DGeometryNode]
>> >>
>> >> SFNode [in,out] metadata NULL [X3DMetadataObject]
>> >>
>> >> SFBool [in,out] visible TRUE
>> >>
>> >> SFVec3f [] bboxCenter 0 0 0 (-∞,∞)
>> >>
>> >> SFVec3f [] bboxSize -1 -1 -1 [0,∞) or −1 −1 −1
>> >>
>> >> }
>> >>
>> >>
>> >>
>> >> Next. Every single node in X3D includes a field named “metadata”, where is allowed to have a single Metadata* node (MetadataBoolean, MetadataFloat, etc.).
>> >>
>> >>
>> >>
>> >> X3D Architecture reference:
>> >>
>> >>
>> >>
>> >> 7.3.5 X3DNode
>> >> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-IS.proof/Part01/components/core.html#X3DNode
>> >>
>> >>
>> >>
>> >> X3DNode {
>> >>
>> >> SFNode [in,out] metadata NULL [X3DMetadataObject]
>> >>
>> >> }
>> >>
>> >> This abstract node type is the base type for all nodes and node types in the X3D system.
>> >>
>> >> The metadata field provides information about the current node contents, as described in 7.2.4 Metadata.
>> >>
>> >>
>> >>
>> >> The X3D XML encoding uses containerField as a way to explicitly set the relationship of a given node to its parent node.
>> >>
>> >>
>> >>
>> >> X3D Scene Authoring Hints: containerField
>> >> https://www.web3d.org/x3d/content/examples/X3dSceneAuthoringHints.html#containerField
>> >>
>> >> Addition of containerField values only occurs in the XML encoding of .x3d scenes. For example: <Transform><Shape containerField='children'/></Transform> indicates that the Shape node is one of the children of the Transform node.
>> >>
>> >> The X3D XML Schema, X3D DTD and X3D Tooltips each define all default containerField values, which are optional and typically can be omitted for scene terseness.
>> >>
>> >> o Usually ignorable. Default containerField values for each node are correct in most cases, so the need to override default containerField values is relatively rare.
>> >>
>> >> o Terse match to other X3D encodings. The containerField attribute is part of XML encoding for X3D scenes, and corresponds to the always-declared field labels in the ClassicVRML and VRML97 file encodings.
>> >>
>> >> o Examples. Example values include containerField='geometry' for Box node, containerField='children' for Group node, containerField='proxy' for hidden proxy shape within a Collision node, etc.
>> >>
>> >> o USE node flexibility. USE nodes are allowed to have a containerField value that is different than the corresponding DEF declaration of that node, since the containerField attribute describes each node's relationship with its parent.
>> >>
>> >> o ProtoInstance node flexibility. ProtoInstance nodes are similarly allowed to have a containerField value that is different than default for their node type, again since the containerField attribute describes each node's relationship with its parent.
>> >>
>> >> Disambiguation of parent-child field relationships is sometimes necessary, since a few parent nodes have more than one child field that can accept the same node type. In those ambiguous cases, the child node must have a correct containerField value in order to precisely define the correct parent-child field relationship with its parent node.
>> >>
>> >> Additional guidance and detail follow there, trying to explain the specification with examples. It is simply offered as helpful information. The X3D Architecture remains the controlling normative reference.
>> >>
>> >> Only the various Metadata* nodes have a field called “value”. Like every other X3D node, they also have a field called “metadata” too.
>> >>
>> >>
>> >>
>> >> X3D Architecture reference:
>> >>
>> >>
>> >>
>> >> 7.4 Node reference
>> >> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-IS.proof/Part01/components/core.html#NodeReference
>> >>
>> >>
>> >>
>> >> 7.4.1 MetadataBoolean
>> >>
>> >> MetadataBoolean : X3DNode, X3DMetadataObject {
>> >>
>> >> SFNode [in,out] metadata NULL [X3DMetadataObject]
>> >>
>> >> SFString [in,out] name ""
>> >>
>> >> SFString [in,out] reference ""
>> >>
>> >> MFBool [in,out] value []
>> >>
>> >> }
>> >>
>> >> The value field provides a list of Boolean metadata whose meaning is specified by the name field.
>> >>
>> >> 7.4.2 MetadataDouble
>> >>
>> >> MetadataDouble : X3DNode, X3DMetadataObject {
>> >>
>> >> SFNode [in,out] metadata NULL [X3DMetadataObject]
>> >>
>> >> SFString [in,out] name ""
>> >>
>> >> SFString [in,out] reference ""
>> >>
>> >> MFDouble [in,out] value []
>> >>
>> >> }
>> >>
>> >> The value field provides a list of double-precision floating-point metadata whose meaning is specified by the name field.
>> >>
>> >> 7.4.3 MetadataFloat
>> >>
>> >> MetadataFloat : X3DNode, X3DMetadataObject {
>> >>
>> >> SFNode [in,out] metadata NULL [X3DMetadataObject]
>> >>
>> >> SFString [in,out] name ""
>> >>
>> >> SFString [in,out] reference ""
>> >>
>> >> MFFloat [in,out] value []
>> >>
>> >> }
>> >>
>> >> The value field provides a list of single-precision floating-point metadata whose meaning is specified by the name field.
>> >>
>> >> 7.4.4 MetadataInteger
>> >>
>> >> MetadataInteger : X3DNode, X3DMetadataObject {
>> >>
>> >> SFNode [in,out] metadata NULL [X3DMetadataObject]
>> >>
>> >> SFString [in,out] name ""
>> >>
>> >> SFString [in,out] reference ""
>> >>
>> >> MFInt32 [in,out] value []
>> >>
>> >> }
>> >>
>> >> The value field provides a list of integer metadata whose meaning is specified by the name field.
>> >>
>> >> 7.4.5 MetadataSet
>> >>
>> >> MetadataSet : X3DNode, X3DMetadataObject {
>> >>
>> >> SFNode [in,out] metadata NULL [X3DMetadataObject]
>> >>
>> >> SFString [in,out] name ""
>> >>
>> >> SFString [in,out] reference ""
>> >>
>> >> MFNode [in,out] value [] [X3DMetadataObject]
>> >>
>> >> }
>> >>
>> >> The value field provides a list of X3DMetadataObject nodes whose meaning is specified by the name field.
>> >>
>> >> 7.4.6 MetadataString
>> >>
>> >> MetadataString : X3DNode, X3DMetadataObject {
>> >>
>> >> SFNode [in,out] metadata NULL [X3DMetadataObject]
>> >>
>> >> SFString [in,out] name ""
>> >>
>> >> SFString [in,out] reference ""
>> >>
>> >> MFString [in,out] value []
>> >>
>> >> }
>> >>
>> >> The value field provides a list of string metadata whose meaning is specified by the name field.
>> >>
>> >> As shown above in the specification, only the MetadataSet node can contain Metadata* nodes in either a metadata field, a value field, or both. So MetadataSet is the tricky node to watch out for.
>> >>
>> >>
>> >>
>> >> Example:
>> >>
>> >>
>> >>
>> >> <Shape>
>> >>
>> >> <MetadataSet DEF=’TripleTroubleExample’ containerField=’metadata’>
>> >>
>> >> <MetadataBoolean DEF=’SomeBooleanArray’ value=”true false true” containerField=’metadata’/>
>> >>
>> >> <MetadataInteger DEF=’SomeIntegerArray’ value=’-1 -2 0 1 2 3 4’ containerField=’value’/>
>> >>
>> >> <MetadataDouble DEF=’SomeDoubleArray’ value=’5.0 6.28 777.7’ containerField=’value’/>
>> >>
>> >> </MetadataSet>
>> >>
>> >> </Shape
>> >>
>> >>
>> >>
>> >> Because MetadataSet can only contain one node in its metadata field, only one of these contained nodes can be containerField=’metadata’ and still be correct.
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> Remember, all of this containerField business is only for terseness of the XML encoding. It has nothing to do with equivalent X3D representations in ClassicVRML, JSON, Python, Java, Turtle, etc.
>> >>
>> >>
>> >>
>> >> Easy to forget… Uh, did you remember that?
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> Evolutionary trickiness is next (as if all this weren’t tricky enough already).
>> >>
>> >>
>> >>
>> >> Experience in X3D3 showed that multiple metadata nodes were used, complex metadata sets became extremely verbose because containerField values were listed everywhere. In fact, they were so verbose that it became hard to read and process the sets of metadata being collected together! Ouch.
>> >>
>> >>
>> >>
>> >> After much debate and experimentation, we decided to lean towards the future where there might be inclusion of quite a lot of metadata sets when converting from CAD, converting from other model formats, expressing new X3D node values, etc. etc.
>> >>
>> >>
>> >>
>> >> As a result we changed the default containerField values (for Metadata* nodes only) in the X3D version 4 XML encoding. This had no impact on the vast majority of X3D scenes out there.
>> >>
>> >>
>> >>
>> >> Thus, if containerField is omitted for terseness in a given scene fragment, the XML might look different for X3D3 versus X3D4. The X3D being modeled is not different.
>> >>
>> >>
>> >>
>> >> The above TripleTroubleExample will always be correct in every version of X3D, because the containerField field names are explicitly defined. Including containerField is never wrong.
>> >>
>> >>
>> >>
>> >> Here are two variations on the above example that omit default containerField entries, for X3D 3.3 and X3D 4.0 respectively.
>> >>
>> >>
>> >>
>> >> <Shape>
>> >>
>> >> <MetadataSet DEF=’TripleTroubleExampleX3D3’ >
>> >>
>> >> <MetadataBoolean DEF=’SomeBooleanArray’ value=”true false true” />
>> >>
>> >> <MetadataInteger DEF=’SomeIntegerArray’ value=’-1 -2 0 1 2 3 4’ containerField=’value’/>
>> >>
>> >> <MetadataDouble DEF=’SomeDoubleArray’ value=’5.0 6.28 777.7’ containerField=’value’/>
>> >>
>> >> <!- - containerField always necessary in subsequent MetadataSet subtree values - ->
>> >>
>> >> </MetadataSet>
>> >>
>> >> </Shape
>> >>
>> >>
>> >>
>> >> or
>> >>
>> >>
>> >>
>> >> <Shape>
>> >>
>> >> <MetadataSet DEF=’TripleTroubleExampleX3D4’ containerField=’metadata’>
>> >>
>> >> <MetadataBoolean DEF=’SomeBooleanArray’ value=”true false true” containerField=’metadata’/>
>> >>
>> >> <MetadataInteger DEF=’SomeIntegerArray’ value=’-1 -2 0 1 2 3 4’ />
>> >>
>> >> <MetadataDouble DEF=’SomeDoubleArray’ value=’5.0 6.28 777.7’ />
>> >>
>> >> <!- - containerField not necessary in subsequent MetadataSet subtree values - ->
>> >>
>> >> </MetadataSet>
>> >>
>> >> </Shape
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> As before, the XML terseness has nothing to do with equivalent X3D representations in ClassicVRML, JSON, Python, Java, Turtle, etc.
>> >>
>> >>
>> >>
>> >> Yes, it is good to remember that.
>> >>
>> >>
>> >>
>> >> So, any X3D JSON representations will always have the field name defined.
>> >>
>> >>
>> >>
>> >> Hopefully this explanation helps determine whether the X3dToJSON.xslt stylesheet is correct already. If not, we will fix it, just as your latest testing has identified some necessary fixes in the X3dToJava.xslt stylesheet.
>> >>
>> >>
>> >>
>> >> Having good repeatable examples in the X3D Example Archives to test things is always helpful. Perhaps the above example snippets can help.
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> Your mileage may vary (YMMV).
>> >>
>> >>
>> >>
>> >> Nevertheless the X3D scene graph defined by the X3D Architecture international specification is unambiguous.
>> >>
>> >>
>> >>
>> >> As ever, improving our XML/JSON schema validation, and diagnostic/conversion tools, and unit-test examples all helps.
>> >>
>> >>
>> >>
>> >> Have fun with X3D – or else! 8)
>> >>
>> >>
>> >>
>> >> 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: John Carlson <yottzumm at gmail.com>
>> >> Sent: Friday, June 30, 2023 11:22 PM
>> >> To: Brutzman, Donald (Don) (CIV) <brutzman at nps.edu>
>> >> Cc: X3D Graphics public mailing list <x3d-public at web3d.org>
>> >> Subject: Re: Is https://www.web3d.org/specifications/java/examples/HelloWorldProgramOutput.json valid?
>> >>
>> >>
>> >>
>> >> I'm not too worried about JSON schema, I just want to make sure that the X3D JSON is right, per the X3D4 standard architecture, with my own eyeballs. I may just have a misunderstanding of the following Shape standard. I don't see a value field, just a metadata field. I realize value may be otherwise specified, but it's not in X3D tooltips either, under Shape.
>> >>
>> >>
>> >>
>> >> https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/components/shape.html#Shape
>> >>
>> >>
>> >>
>> >> I'm not seeing that Shape has a value field, but I'm not too clear on whether containerField equal to "metadata" or "value" should be used on MetadataXxx statements in Shape and Text nodes in JSON. It's highly possible that I'm totally misunderstanding.
>> >>
>> >>
>> >> I understand that both -value and @value are likely possible at some point!
>> >>
>> >>
>> >>
>> >> Here are my diffs to the HelloWorldProgramOutput.json to make it pass:
>> >>
>> >>
>> >>
>> >> --- a/src/main/data/HelloWorldProgramOutput.json
>> >>
>> >> +++ b/src/main/data/HelloWorldProgramOutput.json
>> >>
>> >> @@ -156,7 +156,7 @@
>> >>
>> >> },
>> >>
>> >> {
>> >>
>> >> "@name":"translated",
>> >>
>> >> - "@content":"29 June 2023"
>> >>
>> >> + "@content":"30 June 2023"
>> >>
>> >> },
>> >>
>> >> {
>> >>
>> >> "@name":"generator",
>> >>
>> >> @@ -950,15 +950,14 @@
>> >>
>> >> "-children":[
>> >>
>> >> { "Shape":
>> >>
>> >> {
>> >>
>> >> - "-value":[
>> >>
>> >> + "-metadata":
>> >>
>> >> { "MetadataString":
>> >>
>> >> {
>> >>
>> >> "@name":"findThisNameValue",
>> >>
>> >> "@DEF":"FindableMetadataStringTest",
>> >>
>> >> "@value":["test case"]
>> >>
>> >> }
>> >>
>> >> - }
>> >>
>> >> - ],
>> >>
>> >> + },
>> >>
>> >> "-appearance":
>> >>
>> >> { "Appearance":
>> >>
>> >> {
>> >>
>> >> @@ -2206,15 +2205,14 @@
>> >>
>> >> "-children":[
>> >>
>> >> { "Shape":
>> >>
>> >> {
>> >>
>> >> - "-value":[
>> >>
>> >> + "-metadata":
>> >>
>> >> { "MetadataString":
>> >>
>> >> {
>> >>
>> >> "@name":"findThisNameValue",
>> >>
>> >> "@DEF":"FindableMetadataStringTest",
>> >>
>> >> "@value":["test case"]
>> >>
>> >> }
>> >>
>> >> - }
>> >>
>> >> - ],
>> >>
>> >> + },
>> >>
>> >> "-appearance":
>> >>
>> >> { "Appearance":
>> >>
>> >> {
>> >>
>> >>
>> >>
>> >> Here's the diff to XML I have locally to make the JSON pass. See the blue containerField.
>> >>
>> >>
>> >>
>> >> diff --git a/src/main/data/HelloWorldProgramOutput.x3d b/src/main/data/HelloWorldProgramOutput.x3d
>> >>
>> >> index 99b309451..0d47bfed3 100644
>> >>
>> >> --- a/src/main/data/HelloWorldProgramOutput.x3d
>> >>
>> >> +++ b/src/main/data/HelloWorldProgramOutput.x3d
>> >>
>> >> @@ -246,7 +246,7 @@ function clockTrigger (timeValue)
>> >>
>> >> <!-- Test success: declarative statement createDeclarativeShapeTests() -->
>> >>
>> >> <Group DEF='DeclarativeGroupExample'>
>> >>
>> >> <Shape>
>> >>
>> >> - <MetadataString DEF='FindableMetadataStringTest' name='findThisNameValue' value='"test case"'/>
>> >>
>> >> + <MetadataString DEF='FindableMetadataStringTest' containerField='metadata' name='findThisNameValue' value='"test case"'/>
>> >>
>> >> <Appearance DEF='DeclarativeAppearanceExample'>
>> >>
>> >> <!-- DeclarativeMaterialExample gets overridden by subsequently added MaterialModulator ProtoInstance -->
>> >>
>> >> <ProtoInstance DEF='MyMaterialModulator' name='MaterialModulator' containerField='material'/>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> Thanks for a second set of eyeballs on this.
>> >>
>> >>
>> >>
>> >> My guess is that X3DJSAIL is not reporting a containerField when it should, to produce a processable HelloWorldProgramOutput.x3d that will produce good JSON. I do not have intermediate code right now.
>> >>
>> >>
>> >>
>> >> So actually, it has nothing to do with JSON and everything to do with X3DJSAIL XML output. But yeah, if you want to fix it in X3DJSAIL instead of X3dToJson.xslt, that would probably be easier, and very cool.
>> >>
>> >>
>> >>
>> >> John
>> >>
>> >>
>> >>
>> >> On Sat, Jul 1, 2023 at 12:28 AM Brutzman, Donald (Don) (CIV) <brutzman at nps.edu> wrote:
>> >>
>> >> Hi John. All of the JSON that you find is produced by our X3dToJson.xslt stylesheet, which hopefully meets all patterns we derived and documented at
>> >>
>> >>
>> >>
>> >> X3D to JSON Stylesheet Converter
>> >> https://www.web3d.org/x3d/stylesheets/X3dToJson.html
>> >>
>> >>
>> >>
>> >> Well-formed JSON can be checked. All of our online examples have a link to check via JSONLint, though tonight it is saying “unable to connect” (while providing plenty of advertising).
>> >>
>> >>
>> >>
>> >> X3D Example Archives: X3D4WA, X3D for Web Authors, Chapter 01 Technical Overview, Hello World
>> >> https://x3dgraphics.com/examples/X3dForWebAuthors/Chapter01TechnicalOverview/HelloWorldIndex.html
>> >> upper-right inset box of links: .json (check)
>> >> https://jsonlint.com/?json=https://X3dGraphics.com/examples/X3dForWebAuthors/Chapter01TechnicalOverview/HelloWorld.json
>> >>
>> >>
>> >>
>> >> If there are mistakes in our X3D .xml -> .json pattern or the conversion stylesheet, they can be fixed.
>> >>
>> >>
>> >>
>> >> Strict JSON validation isn’t possible until a JSON Schema is approved. If you think that there is a Java-based implementation of the draft JSON Schema that is mature and stable enough to deserve our time, we can try adding that to our various build tools for X3D Example Archives and X3DJSAIL.
>> >>
>> >>
>> >>
>> >> http://json-schema.org
>> >>
>> >>
>> >>
>> >> 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: John Carlson <yottzumm at gmail.com>
>> >> Sent: Friday, June 30, 2023 8:24 PM
>> >> To: Brutzman, Donald (Don) (CIV) <brutzman at nps.edu>
>> >> Cc: X3D Graphics public mailing list <x3d-public at web3d.org>
>> >> Subject: Is https://www.web3d.org/specifications/java/examples/HelloWorldProgramOutput.json valid?
>> >>
>> >>
>> >>
>> >> Don, if
>> >>
>> >>
>> >>
>> >> https://www.web3d.org/specifications/java/examples/HelloWorldProgramOutput.json
>> >>
>> >>
>> >>
>> >> is supposed to be valid X3D JSON, please inform me. Thanks!
>> >>
>> >>
>> >>
>> >> To ensure that -value is not a field of Shape in JSON, I have added the following exception in x3djsonld.py.
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> if parent in ("Text", "Shape") and key in ("value"): # don't have value yet, sorry
>> >>
>> >> # do value later
>> >>
>> >> raise "-value not a supported field of Text or Shape, try -metadata?"
>> >>
>> >> continue
>> >>
>> >>
>> >>
>> >> I can revert the code if necessary. I'm trying to follow the standard as I see it.
>> >>
>> >>
>> >>
>> >> If -value under Shape is correct, then X3DJSAIL needs to support addValue (as I have it in Java) or setValue. That's my opinion.
>> >>
>> >>
>> >>
>> >> John
>> >
>> > _______________________________________________
>> > x3d-public mailing list
>> > x3d-public at web3d.org
>> > http://web3d.org/mailman/listinfo/x3d-public_web3d.org
More information about the x3d-public
mailing list