[x3d-public] "deep dive" on containerField and value fields for Metadata* node examples

John Carlson yottzumm at gmail.com
Wed Jul 19 13:06:14 PDT 2023


I had posted this to the wrong email address on the wrong thread.


śr., 19 lip 2023 o 04:00 John Carlson <yottzumm at gmail.com> napisał(a):
>
>” Hint: typically use containerField="value" if the parent node is
MetadataSet”
>
> If the parent isn’t a MetadataSet, my understanding is it seeks upward
for a node with a “metadata” or “value” field, depending on what parent
“fits.” For example, a field element element has a value field.

>
> In my Shape JSON case, the schema was complaining about the -value field
under Shape, which doesn’t exist.  If you wanted the field to fit under
Shape, put it under the -metadata node, else seek upwards.

The containerField was not specified in this case, so it chose default
containerField=“value” instead of the Shape’s -metadata field.

>
> So as you seek upward, you can choose first -value field, then -metadata
field
>

This is for defaulted containerFields.  If you specify the wrong
containerField, the XML to JSON transform should throw an error (which it
might?)

John



On Tue, Jul 18, 2023 at 1:46 AM Brutzman, Donald (Don) (CIV) <
brutzman at nps.edu> wrote:

> Thanks for asking Michalis.
>
>
>
> The XML encoding is pretty precisely specified by XML Schema and XML
> DOCTYPE for validating .x3d scenes.  Both of those will be going into the
> X3D XML Encoding document as informative annexes (as with prior versions).
>
>
>
>    - X3D Specifications: Schema and DOCTYPE Validation
>    - https://www.web3d.org/specifications
>
>
>
>    - X3D XML Schema x3d-4.0.xsd and documentation (latest) – strongly
>    typed
>    - https://www.web3d.org/specifications/x3d-4.0.xsd
>    - https://www.web3d.org/specifications/X3dSchemaDocumentation4.0.html
>
>
>
>    - XML DOCTYPE x3d-4.0.dtd and documentation (latest) – string based
>    - https://www.web3d.org/specifications/x3d-4.0.dtd
>    - https://www.web3d.org/specifications/X3dDoctypeDocumentation4.0.html
>
>
>
> Full details on variations with containerField can be found at
>
>
>
>    - X3D Scene Authoring Hints: containerField
>    - Each containerField value is the field name from the X3D
>    Specification that indicates a contained node's relationship to its parent
>    node.  The use of containerField only occurs in XML-encoded files (.x3d
>    format).
>    -
>    https://www.web3d.org/x3d/content/examples/X3dSceneAuthoringHints.html#containerField
>
>
>
> Your words about default containerField values look correct to me.
>
>
>
> The following X3D Tooltips are provided for all of the Metadata nodes.
>
>
>
>    - *Hint: typically use containerField="value" if the parent node is
>    MetadataSet. *
>    - *Warning: default containerField="metadata" in X3D 3.3 changed to
>    default containerField="value" in X3D 4.0, allowing construction of much
>    terser MetadataSet vocabularies.*
>    - *Hint: explicitly defining containerField for Metadata nodes always
>    allowed and unambiguous across each version of X3D. *
>    - *Hint: each of the Metadata nodes are allowed as top-level root
>    nodes in a scene, if doing that be sure to explicitly define
>    containerField='metadata'. *
>
> *https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-DIS/Part01/concepts.html#Rootnodes
> <https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-DIS/Part01/concepts.html#Rootnodes>
> *
>
>    - *Warning: Metadata nodes can only contain other Metadata nodes.*
>
>
>
>    - https://www.web3d.org/x3d/tooltips/X3dTooltips.html#MetadataBoolean
>    - https://www.web3d.org/x3d/tooltips/X3dTooltips.html#MetadataDouble
>    - https://www.web3d.org/x3d/tooltips/X3dTooltips.html#MetadataFloat
>    - https://www.web3d.org/x3d/tooltips/X3dTooltips.html#MetadataInteger
>    - https://www.web3d.org/x3d/tooltips/X3dTooltips.html#MetadataSet
>    - https://www.web3d.org/x3d/tooltips/X3dTooltips.html#MetadataString
>
>
>
> We did not change any other containerField defaults on any other nodes
> when going from X3D 3.3 to X3D 4.0.
>
>
>
> There is no updated X3D XML Encoding spec yet.  We await final ISO
> publication approval for 19775-1 X3D Architecture, and will next update
> 19775 X3D Scene Access Interface (SAI).  X3D XML can ClassicVRML encodings
> will likely be next after that.
>
>
>
> Thanks for the extra effort on MetadataSet and Metadata* node
> containerField defaults.  Of note is that incorrect usage can usually be
> forgiven based on the type of parent node, and of course it has no impact
> on rendering.  Am expecting that having understandable MetadataSet
> vocabulary constucts will help us with CAD, Medical, HAnim and other
> specialty domains, especially when converting metatada along with models
> themselves, from other formats to X3D for Web publication.
>
>
>
> 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
>
>
>
> -----Original Message-----
> From: Michalis Kamburelis <michalis.kambi at gmail.com>
> Sent: Monday, July 17, 2023 2:55 PM
> To: John Carlson <yottzumm at gmail.com>
> Cc: Brutzman, Donald (Don) (CIV) <brutzman at nps.edu>; Roy Walmsley <
> roy.walmsley at ntlworld.com>; X3D Graphics public mailing list <
> x3d-public at web3d.org>
> Subject: Re: [x3d-public] "deep dive" on containerField and value fields
> for Metadata* node examples
>
>
>
>
>
> 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://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsour
>
> > ceforge.net%2Fp%2Fx3d%2Fcode%2FHEAD%2Ftree%2Fwww.web3d.org%2Fx3d%2Fsty
>
> > lesheets%2Fjava%2Fexamples%2FHelloWorldProgramOutput.json&data=05%7C01
>
> > %7Cbrutzman%40nps.edu%7C731693108d804b43439d08db87109887%7C6d936231a51
>
> > 740ea9199f7578963378e%7C0%7C0%7C638252277571305254%7CUnknown%7CTWFpbGZ
>
> > sb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
>
> > D%7C3000%7C%7C%7C&sdata=3awGJ9ql1wOMT1IRPAJJc3B7fDp2xoLO9dEqNwHEwjA%3D
>
> > &reserved=0
>
> >
>
> > 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.p
>
> >> roof/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.p
>
> >> roof/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.p
>
> >> roof/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.htm
>
> >> l#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.p
>
> >> roof/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/co
>
> >> mponents/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://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fx3d
>
> >> graphics.com%2Fexamples%2FX3dForWebAuthors%2FChapter01TechnicalOvervi
>
> >> ew%2FHelloWorldIndex.html&data=05%7C01%7Cbrutzman%40nps.edu%7C7316931
>
> >> 08d804b43439d08db87109887%7C6d936231a51740ea9199f7578963378e%7C0%7C0%
>
> >> 7C638252277571305254%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQ
>
> >> IjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=FXD0
>
> >> OLCetJnoRpBtkb43%2B34e05Co4zxGqd2w0A9gRfw%3D&reserved=0
>
> >> upper-right inset box of links: .json (check)
>
> >> https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjso
>
> >> nlint.com%2F%3Fjson%3Dhttps%3A%2F%2FX3dGraphics.com%2Fexamples%2FX3dF
>
> >> orWebAuthors%2FChapter01TechnicalOverview%2FHelloWorld.json&data=05%7
>
> >> C01%7Cbrutzman%40nps.edu%7C731693108d804b43439d08db87109887%7C6d93623
>
> >> 1a51740ea9199f7578963378e%7C0%7C0%7C638252277571305254%7CUnknown%7CTW
>
> >> FpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI
>
> >> 6Mn0%3D%7C3000%7C%7C%7C&sdata=Z5Fjc%2Bj6qjqgElokqm8JX5L4%2BuXlzU7Q15O
>
> >> y4fu09U4%3D&reserved=0
>
> >>
>
> >>
>
> >>
>
> >> 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.
>
> >>
>
> >>
>
> >>
>
> >> https://nam10.safelinks.protection.outlook.com/?url=http%3A%2F%2Fjson
>
> >> -schema.org%2F&data=05%7C01%7Cbrutzman%40nps.edu%7C731693108d804b4343
>
> >> 9d08db87109887%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638252277
>
> >> 571461064%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzI
>
> >> iLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=AJHxa%2FtEt%2FJ
>
> >> NiVTXRVAfN4RWaxNvg5mbz9WVaehxmMo%3D&reserved=0
>
> >>
>
> >>
>
> >>
>
> >> 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/HelloWorldProgramO
>
> >> utput.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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20230719/cc1ee4a8/attachment-0001.html>


More information about the x3d-public mailing list