<div dir="auto">Thank you for your analysis Don. I did add X3DChildNode as a parent of all statements, but apparently this was incorrect, so I removed it? Please let me know. If X3DChildNode is not the parent of all statements, there needs to a distinguishing in the object model.<div dir="auto"><br></div><div dir="auto">John</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Jul 29, 2017 6:13 PM, "Don Brutzman" <<a href="mailto:brutzman@nps.edu">brutzman@nps.edu</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Thanks for the close scrutiny of OM4X3D and autogeneration/testing of JSON Schema, John.<br>
<br>
BLUF recommendation: suggest you use current design patterns in existing X3D JSON Schema and we continue refining and improving everything together. In this way, multiple X3D validation designs remain coherent and consistent while refining/evolving. It is much much easier to compare to gain insight, and then incrementally improve matching approaches, than it is to reconcile divergent approaches.<br>
<br>
Detailed analysis follows.<br>
<br>
Sounds like you are using Object Model for X3D (OM4X3D) available at<br>
<br>
<a href="http://www.web3d.org/specifications/X3DObjectModel-3.3.xml" rel="noreferrer" target="_blank">http://www.web3d.org/specifica<wbr>tions/X3DObjectModel-3.3.xml</a><br>
<br>
The content model for contained nodes and statements is generated from the content model for X3D XML Schema, and matches both XML Schema and DTD.<br>
<br>
<a href="http://www.web3d.org/specifications/x3d-3.3.xsd" rel="noreferrer" target="_blank">http://www.web3d.org/specifica<wbr>tions/x3d-3.3.xsd</a><br>
<a href="http://www.web3d.org/specifications/X3dSchemaDocumentation3.3.html" rel="noreferrer" target="_blank">http://www.web3d.org/specifica<wbr>tions/X3dSchemaDocumentation3.<wbr>3.html</a><br>
<br>
<a href="http://www.web3d.org/specifications/x3d-3.3.dtd" rel="noreferrer" target="_blank">http://www.web3d.org/specifica<wbr>tions/x3d-3.3.dtd</a><br>
<a href="http://www.web3d.org/specifications/X3dDoctypeDocumentation3.3.html" rel="noreferrer" target="_blank">http://www.web3d.org/specifica<wbr>tions/X3dDoctypeDocumentation3<wbr>.3.html</a><br>
<br>
Example excerpt follows:<br>
<br>
<AbstractNodeType name="X3DGroupingNode"><br>
<InterfaceDefinition specificationUrl="<a href="http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/group.html#X3DGroupingNode" rel="noreferrer" target="_blank">http://www.w<wbr>eb3d.org/documents/specificati<wbr>ons/19775-1/V3.3/Part01/<wbr>components/group.html#X3DGroup<wbr>ingNode</a>"<br>
appinfo="Grouping nodes can contain other nodes as children, thus making up the backbone of a scene graph."><br>
<componentInfo name="Grouping" level="1"/><br>
<Inheritance baseType="X3DChildNode"/><br>
<AdditionalInheritance baseType="X3DBoundedObject"/><br>
<field type="MFNode"<br>
accessType="inputOnly"<br>
name="addChildren"<br>
acceptableNodeTypes="X3DChild<wbr>Node"><br>
<componentInfo name="Grouping" level="2"/><br>
</field><br>
<field type="SFVec3f"<br>
accessType="initializeOnly"<br>
name="bboxCenter"<br>
default="0 0 0"/><br>
<field type="SFVec3f"<br>
accessType="initializeOnly"<br>
name="bboxSize"<br>
default="-1 -1 -1"<br>
baseType="<wbr>boundingBoxSizeType"/><br>
<field type="MFNode"<br>
accessType="inputOutput"<br>
name="children"<br>
acceptableNodeTypes="X3DChild<wbr>Node"/><br>
<field type="SFNode"<br>
accessType="inputOutput"<br>
name="metadata"<br>
default="NULL"<br>
acceptableNodeTypes="X3DMetad<wbr>ataObject"<br>
inheritedFrom="X3DNode"/><br>
<field type="MFNode"<br>
accessType="inputOnly"<br>
name="removeChildren"<br>
acceptableNodeTypes="X3DChild<wbr>Node"><br>
<componentInfo name="Grouping" level="2"/><br>
</field><br>
<field type="SFString"<br>
accessType="inputOutput"<br>
name="DEF"<br>
inheritedFrom="DEF_USE"/><br>
<field type="SFString"<br>
accessType="inputOutput"<br>
name="USE"<br>
inheritedFrom="DEF_USE"/><br>
<field type="SFString"<br>
accessType="inputOutput"<br>
name="class"<br>
inheritedFrom="globalAttribut<wbr>es"/><br>
<ContentModel><br>
<GroupContentModel name="ChildContentModel" minOccurs="0" maxOccurs="unbounded"/><br>
<GroupContentModel name="ChildContentModelCore" minOccurs="0"/><br>
</ContentModel><br>
</InterfaceDefinition><br>
</AbstractNodeType><br>
<br>
Here is a variant example which includes both primary GroupContentModel and then specificNodeContentModel entries:<br>
<br>
<ConcreteNode name="CADFace"><br>
<InterfaceDefinition specificationUrl="<a href="http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/CADGeometry.html#CADFace" rel="noreferrer" target="_blank">http://www.w<wbr>eb3d.org/documents/specificati<wbr>ons/19775-1/V3.3/Part01/<wbr>components/CADGeometry.html#<wbr>CADFace</a>"><br>
<componentInfo name="CADGeometry" level="2"/><br>
<Inheritance baseType="X3DProductStructureC<wbr>hildNode"/><br>
<AdditionalInheritance baseType="X3DBoundedObject"/><br>
<field type="SFVec3f"<br>
accessType="initializeOnly"<br>
name="bboxCenter"<br>
default="0 0 0"/><br>
<field type="SFVec3f"<br>
accessType="initializeOnly"<br>
name="bboxSize"<br>
default="-1 -1 -1"<br>
baseType="<wbr>boundingBoxSizeType"/><br>
<field type="SFNode"<br>
accessType="inputOutput"<br>
name="metadata"<br>
default="NULL"<br>
acceptableNodeTypes="X3DMetad<wbr>ataObject"<br>
inheritedFrom="X3DNode"/><br>
<field type="SFString"<br>
accessType="inputOutput"<br>
name="name"<br>
inheritedFrom="X3DProductStru<wbr>ctureChildNode"/><br>
<field type="SFNode"<br>
accessType="inputOutput"<br>
name="shape"<br>
default="NULL"<br>
acceptableNodeTypes="Shape|LO<wbr>D|Transform"/><br>
<field type="SFString"<br>
accessType="inputOutput"<br>
name="DEF"<br>
inheritedFrom="DEF_USE"/><br>
<field type="SFString"<br>
accessType="inputOutput"<br>
name="USE"<br>
inheritedFrom="DEF_USE"/><br>
<field type="SFString"<br>
accessType="inputOutput"<br>
name="class"<br>
inheritedFrom="globalAttribut<wbr>es"/><br>
<containerFieldDefault name="children"/><br>
<ContentModel><br>
<GroupContentModel name="ChildContentModelCore" minOccurs="0"/><br>
<NodeContentModel name="Shape"/><br>
<NodeContentModel name="LOD"/><br>
<NodeContentModel name="Transform"/><br>
<NodeContentModel name="ProtoInstance"/><br>
</ContentModel><br>
</InterfaceDefinition><br>
</ConcreteNode><br>
<br>
Here is a particular statement, ROUTE:<br>
<br>
<Statement name="ROUTE"><br>
<InterfaceDefinition specificationUrl="<a href="http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/concepts.html#ModifyingObjectsRoutes" rel="noreferrer" target="_blank">http://www.w<wbr>eb3d.org/documents/specificati<wbr>ons/19775-1/V3.3/Part01/<wbr>concepts.html#ModifyingObjects<wbr>Routes</a>"<br>
appinfo="ROUTE connects output fields of event-producing nodes to input fields of event-consuming nodes."><br>
<componentInfo name="Core" level="1"/><br>
<field type="SFString"<br>
accessType="inputOutput"<br>
name="fromField"<br>
use="required"/><br>
<field type="SFString"<br>
accessType="inputOutput"<br>
name="fromNode"<br>
use="required"/><br>
<field type="SFString"<br>
accessType="inputOutput"<br>
name="toField"<br>
use="required"/><br>
<field type="SFString"<br>
accessType="inputOutput"<br>
name="toNode"<br>
use="required"/><br>
</InterfaceDefinition><br>
</Statement><br>
<br>
However "ROUTE" does not appear elsewhere in OM4X3D. Its presence as a legal child node of X3DGroupingNode is implicit and can only be inferred by looking at ChildContentModel in X3D XML Schema.<br>
<br>
As you have discovered, this appears to be an omission in the OMX3D definitions.<br>
<br>
We certainly do want to keep everything consistent, and so precise treatment to make such a relationship explicit in OM4X3D will require further scrutiny of these design patterns, quite possibly according to the approach that you suggest. Since the X3D content model is pretty involved, and since we are working across multiple encodings and programming languages, it is good to be careful and deliberate about these things.<br>
<br>
Of related interest is to look at how X3DJSAIL handles this relationship by using class (rather than interface) hierarchy:<br>
==============================<wbr>==============================<wbr>=====<br>
<a href="http://www.web3d.org/specifications/java/javadoc/org/web3d/x3d/jsail/Core/ROUTEObject.html" rel="noreferrer" target="_blank">http://www.web3d.org/specifica<wbr>tions/java/javadoc/org/web3d/<wbr>x3d/jsail/Core/ROUTEObject.<wbr>html</a><br>
<br>
org.web3d.x3d.jsail.Core<br>
Class ROUTEObject<br>
java.lang.Object<br>
org.web3d.x3d.jsail.X3DConcret<wbr>eElement<br>
org.web3d.x3d.jsail.X3DConcret<wbr>eStatement<br>
org.web3d.x3d.jsail.Core.ROUTE<wbr>Object<br>
<br>
All Implemented Interfaces:<br>
X3DChildNode, X3DNode<br>
==============================<wbr>==============================<wbr>=====<br>
<br>
Note that since ROUTEObject implements X3DChildNode, it can appear within any X3D<br>
<br>
First, it maintains the X3D interfaces from the X3D Abstract Specification (e.g. X3DChildNode, X3DNode) separate from the object hierarchy.<br>
<br>
Second, since the abstract specification does not list interfaces for statements (root cause of this current design gap), it creates<br>
Class X3DConcreteElement which has two concrete subclasses: X3DConcreteNode and X3DConcreteStatement.<br>
<br>
==============================<wbr>==============================<wbr>=====<br>
<a href="http://www.web3d.org/specifications/java/javadoc/org/web3d/x3d/jsail/X3DConcreteElement.html" rel="noreferrer" target="_blank">http://www.web3d.org/specifica<wbr>tions/java/javadoc/org/web3d/<wbr>x3d/jsail/X3DConcreteElement.<wbr>html</a><br>
<a href="http://www.web3d.org/specifications/java/javadoc/org/web3d/x3d/jsail/package-tree.html" rel="noreferrer" target="_blank">http://www.web3d.org/specifica<wbr>tions/java/javadoc/org/web3d/<wbr>x3d/jsail/package-tree.html</a><br>
<br>
org.web3d.x3d.jsail<br>
Class X3DConcreteElement<br>
java.lang.Object<br>
org.web3d.x3d.jsail.X3DConcret<wbr>eElement<br>
<br>
Direct Known Subclasses:<br>
X3DConcreteNode, X3DConcreteStatement<br>
==============================<wbr>==============================<wbr>=====<br>
<br>
After considering and trying a number of approaches, I left the X3D specification interfaces verbatim/unchanged and handled the necessary additions via this class/subclass approach. It achieves the same content model as X3D specification and XML schema with the addition of strong typing. Strong typing of elements (i.e. nodes or statements) means that creation of a valid scene graph is easily allowed (indeed with choices prompted by IDE). Meanwhile, creation of an invalid scene graph is not permitted since that would violate strong typing requirements and thus fail compilation.<br>
<br>
Next... Looking closely at Roy's manually created X3D JSON schema is particularly important for what you are doing. Some excerpts:<br>
==============================<wbr>==============================<wbr>=====<br>
<a href="http://www.web3d.org/specifications/x3d-3.3-JSONSchema.json" rel="noreferrer" target="_blank">http://www.web3d.org/specifica<wbr>tions/x3d-3.3-JSONSchema.json</a><br>
<a href="http://www.web3d.org/specifications/X3dJsonSchemaDocumentation3.3.html" rel="noreferrer" target="_blank">http://www.web3d.org/specifica<wbr>tions/X3dJsonSchemaDocumentati<wbr>on3.3.html</a><br>
<br>
JSON Schema definition, Group documentation:<br>
<a href="http://www.web3d.org/specifications/X3dJsonSchemaDocumentation3.3/x3d-3.3-JSONSchema.html#Link54" rel="noreferrer" target="_blank">http://www.web3d.org/specifica<wbr>tions/X3dJsonSchemaDocumentati<wbr>on3.3/x3d-3.3-JSONSchema.html#<wbr>Link54</a><br>
<br>
"Group": {<br>
"type": "object",<br>
"properties": {<br>
"@DEF": {<br>
"type": "string"<br>
},<br>
"@USE": {<br>
"type": "string"<br>
},<br>
"IS": {<br>
"$ref": "#/definitions/IS"<br>
},<br>
"@bboxCenter": {<br>
"type": "array",<br>
"minItems": 3,<br>
"maxItems": 3,<br>
"items": {<br>
"type": "number",<br>
"default": 0<br>
}<br>
},<br>
"@bboxSize": {<br>
"$ref": "#/definitions/@bboxSize"<br>
},<br>
"-children": {<br>
"$ref": "#/definitions/-children"<br>
},<br>
"-metadata": {<br>
"$ref": "#/definitions/-metadata"<br>
}<br>
},<br>
"additionalProperties": false<br>
}<br>
<br>
==============================<wbr>==============================<wbr>=====<br>
JSON Schema definition, CADFace documentation:<br>
<a href="http://www.web3d.org/specifications/X3dJsonSchemaDocumentation3.3/x3d-3.3-JSONSchema.html#Link12" rel="noreferrer" target="_blank">http://www.web3d.org/specifica<wbr>tions/X3dJsonSchemaDocumentati<wbr>on3.3/x3d-3.3-JSONSchema.html#<wbr>Link12</a><br>
<br>
"CADFace": {<br>
"type": "object",<br>
"properties": {<br>
"@DEF": {<br>
"type": "string"<br>
},<br>
"@USE": {<br>
"type": "string"<br>
},<br>
"IS": {<br>
"$ref": "#/definitions/IS"<br>
},<br>
"@bboxCenter": {<br>
"type": "array",<br>
"minItems": 3,<br>
"maxItems": 3,<br>
"items": {<br>
"type": "number",<br>
"default": 0<br>
}<br>
},<br>
"@bboxSize": {<br>
"$ref": "#/definitions/@bboxSize"<br>
},<br>
"@name": {<br>
"type": "string"<br>
},<br>
"-metadata": {<br>
"$ref": "#/definitions/-metadata"<br>
},<br>
"-shape": {<br>
"type": "object",<br>
"properties": {<br>
"LOD": {<br>
"$ref": "#/definitions/LOD"<br>
},<br>
"Shape": {<br>
"$ref": "#/definitions/Shape"<br>
},<br>
"Transform": {<br>
"$ref": "#/definitions/Transform"<br>
},<br>
"ProtoInstance": {<br>
"$ref": "#/definitions/ProtoInstance"<br>
}<br>
},<br>
"additionalProperties": false<br>
},<br>
"-children": {<br>
"$ref": "#/definitions/-commentRoute"<br>
}<br>
},<br>
"additionalProperties": false<br>
},<br>
<br>
==============================<wbr>==============================<wbr>=====<br>
JSON Schema definition -children<br>
<a href="http://www.web3d.org/specifications/X3dJsonSchemaDocumentation3.3/x3d-3.3-JSONSchema.html#Link107" rel="noreferrer" target="_blank">http://www.web3d.org/specifica<wbr>tions/X3dJsonSchemaDocumentati<wbr>on3.3/x3d-3.3-JSONSchema.html#<wbr>Link107</a><br>
<br>
(scroll down to "source code)<br>
<br>
"-children": {<br>
"description": "MF X3DChildNode content",<br>
"type": "array",<br>
"minItems": 1,<br>
"items": {<br>
"type": "object",<br>
"properties": {<br>
"#comment": {<br>
"type": "string"<br>
},<br>
"ProtoInstance": {<br>
"$ref": "#/definitions/ProtoInstance"<br>
},<br>
"Anchor": {<br>
"$ref": "#/definitions/Anchor"<br>
},<br>
"AudioClip": {<br>
"$ref": "#/definitions/AudioClip"<br>
},<br>
"Background": {<br>
"$ref": "#/definitions/Background"<br>
},<br>
<br>
[... many nodes skipped ...]<br>
"VolumePickSensor": {<br>
"$ref": "#/definitions/VolumePickSenso<wbr>r"<br>
},<br>
"WorldInfo": {<br>
"$ref": "#/definitions/WorldInfo"<br>
},<br>
"ROUTE": {<br>
"$ref": "#/definitions/ROUTE"<br>
},<br>
"ProtoDeclare": {<br>
"$ref": "#/definitions/ProtoDeclare"<br>
},<br>
"ExternProtoDeclare": {<br>
"$ref": "#/definitions/ExternProtoDecl<wbr>are"<br>
},<br>
"IMPORT": {<br>
"$ref": "#/definitions/IMPORT"<br>
},<br>
"EXPORT": {<br>
"$ref": "#/definitions/EXPORT"<br>
}<br>
},<br>
"additionalProperties": false<br>
}<br>
}<br>
==============================<wbr>==============================<wbr>=====<br>
<br>
Point worth noting in preceding: we gave comment and ROUTE the prefix key "-children". I think we should take a similar approach for IMPORT and EXPORT if they appear within nodes that are not X3DGroupingNode.<br>
<br>
So, hope this helps, please advise what you think.<br>
<br>
v/r Don<br>
<br>
<br>
On 7/29/2017 1:11 PM, John Carlson wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Are we assuming that can acceptableNodeTypes in the object model will allow for acceptableStatements? I'd like to see action on this in the object model (put the statements or abstract types for statements into acceptableNodeTypes) so I can continue with autogeneration of the JSON schema.<br>
<br>
On Jul 20, 2017 1:22 PM, "John Carlson" <<a href="mailto:yottzumm@gmail.com" target="_blank">yottzumm@gmail.com</a> <mailto:<a href="mailto:yottzumm@gmail.com" target="_blank">yottzumm@gmail.com</a>>> wrote:<br>
__ __<br>
<br>
I believe we need acceptableStatements to restrict acceptable statements for children fields in the X3D Object Model. If it’s ProtoInstance we have a acceptable statements which are comments. If no children field is found, then we have -commentRoute in JSON schema (temporarily now -childrenStatements). However if there are children, there’s no way to specify which statements are allowed. Previously, I tacked X3DChildNode above the statement inheritance hierarchy in my schema generator, which was wrong.<br>
<br>
__ __<br>
<br>
Do we need to extend this extra children field to other nodes so they can accept statements? And then just don’t support any acceptableNodeTypes for those children?____<br>
<br>
__ __<br>
<br>
Can we separate nodes and statements into separate children arrays in X3DJSON?____<br>
<br>
__ __<br>
<br>
Things to think about.____<br>
</blockquote>
<br>
<br>
all the best, Don<br>
-- <br>
Don Brutzman Naval Postgraduate School, Code USW/Br <a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a><br>
Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA <a href="tel:%2B1.831.656.2149" value="+18316562149" target="_blank">+1.831.656.2149</a><br>
X3D graphics, virtual worlds, navy robotics <a href="http://faculty.nps.edu/brutzman" rel="noreferrer" target="_blank">http://faculty.nps.edu/brutzma<wbr>n</a><br>
</blockquote></div></div>