<div dir="ltr">Again thanks for noticing Holger that some work had been done with IMPORT/EXPORT. Change summaries are found in Mantis, reviews of draft specification prose are performed by Dick Puk and I as specification editors.<div><ul><li>Mantis 1470: add EXPORT/IMPORT field DESCRIPTION for X3D Architecture 4.1</li><li><a href="https://mantis.web3d.org/view.php?id=1470">https://mantis.web3d.org/view.php?id=1470</a></li></ul>Primary motivation follows for this proposed change, and much further detail appears in the Mantis issue.</div><div><ul><li>X3D EXPORT/IMPORT is a powerful extensibility mechanism for simply sharing model characteristics for scene interoperability, animation, and repeatable reuse.</li><li>Adding a DESCRIPTION field to these statements for X3D Architecture 4.1 will help authors describe the purpose of the nodes and fields that the EXPORT and IMPORT statements are referring to. This will help document author intent for shared comprehension and correct usage of IMPORT/EXPORT for these models.</li><li>Aside from supporting persistent parsing of a string (and optional interface display) of each DESCRIPTION, no further functionality is required of browser implementations.</li></ul></div><div><div>Here is current draft:</div><div><ul><li>X3D v4.1 Draft Architecture, clause 9 Networking component</li><li>9.2.5 IMPORT statement and 9.2.6 EXPORT statement</li><li><a href="https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/components/networking.html#IMPORTStatement">https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/components/networking.html#IMPORTStatement</a></li><li><a href="https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/components/networking.html#EXPORTStatement">https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/components/networking.html#EXPORTStatement</a></li></ul><div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><span class="gmail-proposed" title="Mantis 1470" style="background-color:yellow"><font size="2">9.2.5 IMPORT statement<br></font></span>The IMPORT statement is used within an X3D file to specify nodes, which are defined within Inline files or programmatically created content, that are to be brought into the namespace of the containing file for the purposes of event routing. Once a node is imported, events may be sent to its fields via ROUTEs, or routed from any fields of the node which have output events. <span class="gmail-proposed" title="Mantis 1470" style="background-color:yellow">DEF names are used to identify nodes.<br></span>IMPORT statements may appear anywhere in the file and have the following form:<br><span class="gmail-code" style="font-family:monospace">IMPORT <InlineNodeDEFName><b>.</b><ExportedNameFromInlinedFile> [ AS <NewLocalNodeDEFName> ]<br></span><span class="gmail-code" style="font-family:monospace"> [DESCRIPTION "a simple description of intended IMPORT purpose"]<br></span><span class="gmail-code" style="font-family:monospace">IMPORT <InlineNodeName><b>.</b><ExportedNameFromInlinedFile> [ AS <NewLocalNodeName> ]<br></span>The IMPORT statement has the following components:<ol type="a" style="color:rgb(0,0,0);font-family:Verdana,Arial,Helvetica,sans-serif"><li style="margin-top:4px">The <span class="gmail-proposed" title="Mantis 1470" style="background-color:yellow">DEF</span> name of the Inline node that contains the node to be imported,</li></ol><ol type="a" style="color:rgb(0,0,0);font-family:Verdana,Arial,Helvetica,sans-serif"><li style="margin-top:4px">The <span class="gmail-proposed" title="Mantis 1470" style="background-color:yellow">DEF</span> name of the node to import,</li></ol><ol type="a" style="color:rgb(0,0,0);font-family:Verdana,Arial,Helvetica,sans-serif"><li style="margin-top:4px">An optional <span class="gmail-proposed" title="Mantis 1470" style="background-color:yellow">alternative DEF</span> name that is used <span class="gmail-proposed" title="Mantis 1470" style="background-color:yellow">AS</span> <span class="gmail-proposedDeletion" title="Mantis 1470" style="background-color:orange;text-decoration-line:line-through">as</span> an alias for the imported node within the run-time name scope, to <span class="gmail-proposedDeletion" title="Mantis 1470" style="background-color:orange;text-decoration-line:line-through">help prevent</span> <span class="gmail-proposed" title="Mantis 1470" style="background-color:yellow">avoid potential DEF</span> name clashes within the parent scene containing the IMPORT statement,</li></ol><ol type="a" style="color:rgb(0,0,0);font-family:Verdana,Arial,Helvetica,sans-serif"><li style="margin-top:4px"><span class="gmail-proposed" title="Mantis 1470" style="background-color:yellow">An optional simple DESCRIPTION of intended purpose for the node provided via IMPORT.</span></li></ol>The IMPORT statement has the following semantics:<ol type="a" start="4" style="color:rgb(0,0,0);font-family:Verdana,Arial,Helvetica,sans-serif"><li style="margin-top:4px">Once imported, events may be routed to or from the <span class="gmail-proposed" title="Mantis 1470" style="background-color:yellow">fields of an</span> imported node <span class="gmail-proposed" title="Mantis 1470" style="background-color:yellow">in the Inline scene,</span> in exactly the same manner as any node defined <span class="gmail-proposed" title="Mantis 1470" style="background-color:yellow">locally</span> with DEF.</li></ol><ol type="a" start="4" style="color:rgb(0,0,0);font-family:Verdana,Arial,Helvetica,sans-serif"><li style="margin-top:4px">Nodes imported into an X3D scene using the IMPORT statement may not be instanced via the USE statement.</li></ol><ol type="a" start="4" style="color:rgb(0,0,0);font-family:Verdana,Arial,Helvetica,sans-serif"><li style="margin-top:4px">Only nodes that are exported from within the Inline via an EXPORT statement may be imported using a corresponding IMPORT statement.</li></ol><ol type="a" start="4" style="color:rgb(0,0,0);font-family:Verdana,Arial,Helvetica,sans-serif"><li style="margin-top:4px">The IMPORT statement can appear wherever a ROUTE statement is allowed, and shall follow the Inline node to which it refers.</li></ol>The following example illustrates the use of the IMPORT statement (Classic VRML encoding syntax):<br>DEF I1 Inline {<br> url "someurl.x3d"<br>}<br> . . .<br>
IMPORT I1.rootTransform AS I1Root<br>DEF PI PositionInterpolator { ... }<br>ROUTE PI.value_changed TO I1Root.set_translation<br>In the above example, <span class="gmail-code" style="font-family:monospace">rootTransform</span> is defined as a Transform node in the file <code>someurl.x3d</code> and exported via an EXPORT statement (see <a href="https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/concepts.html#EXPORTSemantics">4.4.6.3 EXPORT semantics</a>). The optional AS keyword defines an alias for <span class="gmail-proposed" title="Mantis 1470" style="background-color:yellow">the</span> <span class="gmail-code" style="font-family:monospace">rootTransform</span> <span class="gmail-proposed" title="Mantis 1470" style="background-color:yellow">DEF,</span> so that within the containing scene the node is referenced using the DEF name <span class="gmail-code" style="font-family:monospace">I1Root</span>. All defined alias AS names shall also meet appropriate uniqueness requirements in the local DEF namespace of the parent scene.<br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> </blockquote><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><font size="2"><span class="gmail-proposed" title="Mantis 1470" style="background-color:yellow">9.2.6 EXPORT statement<br></span></font>The EXPORT statement is used within an X3D file to specify nodes that may be imported into other scenes when Inlining that file. Only named nodes exported with an EXPORT statement are eligible to be imported into another <span class="gmail-proposed" title="Mantis 1470" style="background-color:yellow">scene.</span> <span class="gmail-proposedDeletion" title="Mantis 1470" style="background-color:orange;text-decoration-line:line-through">file.</span> <span class="gmail-proposed" title="Mantis 1470" style="background-color:yellow">DEF names are used to identify nodes.<br></span>EXPORT statements may appear anywhere in the file and have the following form:<br><span class="gmail-code" style="font-family:monospace">EXPORT <NodeDEFName> [ AS <ExportedNodeDEFName> ]<br></span><span class="gmail-code" style="font-family:monospace"> [DESCRIPTION "a simple description of intended EXPORT purpose"]<br></span><span class="gmail-code" style="font-family:monospace">EXPORT <NodeName> [ AS <ExportedNodeName> ]<br></span>The EXPORT statement has the following components:<ol type="a" style="color:rgb(0,0,0);font-family:Verdana,Arial,Helvetica,sans-serif"><li style="margin-top:4px">The <span class="gmail-proposed" title="Mantis 1470" style="background-color:yellow">local</span> DEF name of the node to be exported <span class="gmail-proposed" title="Mantis 1470" style="background-color:yellow">if the current scene is retrieved externally via Inline,</span></li></ol><ol type="a" style="color:rgb(0,0,0);font-family:Verdana,Arial,Helvetica,sans-serif"><li style="margin-top:4px">An optional <span class="gmail-proposed" title="Mantis 1470" style="background-color:yellow">alternative DEF</span> name that is used <span class="gmail-proposed" title="Mantis 1470" style="background-color:yellow">AS a default</span> <span class="gmail-proposedDeletion" title="Mantis 1470" style="background-color:orange;text-decoration-line:line-through">as an</span> alias for the exported node when importing it into other <span class="gmail-proposed" title="Mantis 1470" style="background-color:yellow">scenes,</span> <span class="gmail-proposedDeletion" title="Mantis 1470" style="background-color:orange;text-decoration-line:line-through">files,</span></li></ol><ol type="a" style="color:rgb(0,0,0);font-family:Verdana,Arial,Helvetica,sans-serif"><li style="margin-top:4px"><span class="gmail-proposed" title="Mantis 1470" style="background-color:yellow">An optional simple DESCRIPTION of intended purpose for the node provided via EXPORT.</span></li></ol>The EXPORT statement has the following semantics:<ol type="a" start="3" style="color:rgb(0,0,0);font-family:Verdana,Arial,Helvetica,sans-serif"><li style="margin-top:4px">Once imported into a containing scene, events may be routed to or from <span class="gmail-proposed" title="Mantis 1470" style="background-color:yellow">the fields of</span> an exported node in exactly the same manner as any node defined with DEF.</li></ol><ol type="a" start="3" style="color:rgb(0,0,0);font-family:Verdana,Arial,Helvetica,sans-serif"><li style="margin-top:4px">Exported nodes imported into a containing scene may not be instanced via the USE statement.</li></ol><ol type="a" start="3" style="color:rgb(0,0,0);font-family:Verdana,Arial,Helvetica,sans-serif"><li style="margin-top:4px">Exportation may not be propagated across multiple files; that is, a node imported into one scene using the IMPORT statement may not then be further exported into another scene using the EXPORT statement.</li></ol><ol type="a" start="3" style="color:rgb(0,0,0);font-family:Verdana,Arial,Helvetica,sans-serif"><li style="margin-top:4px">Nodes shall not be exported from the body of a PROTO declaration.</li></ol><ol type="a" start="3" style="color:rgb(0,0,0);font-family:Verdana,Arial,Helvetica,sans-serif"><li style="margin-top:4px">The EXPORT statement can appear wherever a ROUTE statement is allowed, and shall be contained within the Inline node to which it refers.</li></ol>The following example illustrates the use of the EXPORT statement (Classic VRML encoding):<br>DEF T1 Transform {<br> ...<br>}<br> . . .<br>
EXPORT T1 AS rootTransform<br> In the above example, node <span class="gmail-code" style="font-family:monospace">T1</span> is exported for use by other X3D scenes. The optional AS keyword defines the exported name of <span class="gmail-code" style="font-family:monospace"><b>T1</b></span> as <span class="gmail-code" style="font-family:monospace"><b>rootTransform</b></span> (<i style="">i.e.</i>, other scenes may import the node only using the name <span class="gmail-code" style="font-family:monospace">rootTransform</span>). All defined alias AS names shall also meet appropriate uniqueness requirements in the local DEF namespace of the parent scene.</blockquote></div></div><div><br></div><div>As everyone can see, primary improvements above are clarity. Continuing refinements are of course welcome.</div><div><br></div><div>The <i>description </i>field was shown to be valuable for authors using any of the Sensor nodes in X3D 4.0, further offering authors the ability to communicate semantics and intent to end users.</div></div><div><br></div><div>Adding an optional DESCRIPTION further lets authors communicate semantics and intent to other authors (now and in future) when using this X3D extensibility feature. Such DESCRIPTION information is expected to be a persistent part of the model, not transient or removable as comments are. This gap cannot be filled by Metadata nodes, since they cannot be attached to stateemnts.</div><div><br></div><div>Since IMPORT and EXPORT are statements, rather than nodes, the syntax for those simple DESCRIPTION strings is expected to vary a bit when applied to each of the X3D file formats and programming-language bindings. These will be formally updated as we work through each of the specifications. I'm not ready to add them to the following examples until an X3D 4.1 DOCTYPE and XML Schema are created - sometime this fall I hope. When that is ready, example/suggested syntax will be found at the following pair of example models:</div><div><ul><li><i>X3D Example Archives: Basic, X3D Specifications, Inline Export</i></li><li>X3D encodings example: demonstrate reuse and adaptation of content instances through Inline IMPORT, EXPORT statements. This scene does not animate, see InlineImport.x3d for selective animation of scene subgraph EXPORT localDEF=T1 AS=RootTransform</li><li><a href="https://www.web3d.org/x3d/content/examples/Basic/X3dSpecifications/InlineExportIndex.html">https://www.web3d.org/x3d/content/examples/Basic/X3dSpecifications/InlineExportIndex.html</a></li></ul>and<br><ul><li><i>X3D Example Archives: Basic, X3D Specifications, Inline Import</i><br>X3D encodings example: demonstrate reuse and adaptation of content instances through Inline IMPORT, EXPORT statements. This scene animates only a portion of model InlineExport.x3d that exposes a Transform scene subgraph.</li><li><a href="https://www.web3d.org/x3d/content/examples/Basic/X3dSpecifications/InlineImportIndex.html">https://www.web3d.org/x3d/content/examples/Basic/X3dSpecifications/InlineImportIndex.html</a></li></ul></div><div>Hope this looks sensible. Again, careful scrutiny and all potential improvements are welcome.</div><div><br></div><div>Step by step, onward we go. Have fun with X3D Extensibility using IMPORT/EXPORT!</div><div><br></div><div>all the best, Don</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Mon, Aug 18, 2025 at 7:16 AM Don Brutzman <<a href="mailto:don.brutzman@gmail.com">don.brutzman@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Holger, thanks for these excellent comments on recent specification draft editing.<div><br></div><div>I expect to start working on them later this week. Will report back here, also ensuring that these issues are tracked satisfactorily using Mantis.</div><div><ul><li>Mantis 1510: X3D Architecture 4.1 draft specification errata</li><li><a href="https://mantis.web3d.org/view.php?id=1510" target="_blank">https://mantis.web3d.org/view.php?id=1510</a></li></ul><div>all the best, Don</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Aug 18, 2025 at 4:52 AM Holger Seelig via x3d-public <<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div>Inconsistencies in the draft for 4.1</div><div><br></div><div>* Immersive profile, Full profile, MedicalInterchange profile include now the new FontFamily node but the level for the Text component in these profiles is still 1 but should be 2</div><div><br></div><div>* There is now a new Tangent node, which can be child of a lot of geometry nodes, but should be a possible child of even more nodes, still missing a tangent field: ElevationGrid, PointSet, IndexedLineSet, LineSet. Why? All these nodes also have a normal field and can be affected by lighting and shading with Material or PhysicalMaterial (probably with a normalTexture which then requires a Tangent node). Example of lines and points with normals and shading: <a href="https://create3000.github.io/x_ite/laboratory/gltf-sample-viewer/?url=https://raw.githubusercontent.com/KhronosGroup/glTF-Sample-Models/master/2.0/PrimitiveModeNormalsTest/glTF/PrimitiveModeNormalsTest.gltf" target="_blank">https://create3000.github.io/x_ite/laboratory/gltf-sample-viewer/?url=https://raw.githubusercontent.com/KhronosGroup/glTF-Sample-Models/master/2.0/PrimitiveModeNormalsTest/glTF/PrimitiveModeNormalsTest.gltf</a></div><div><br></div><div>* LayoutGroup is now of type X3DNode but specification says: "Thus, a LayoutGroup can only be a child of a LayoutLayer node or another LayoutGroup node.“ But LayoutGroup children/addChildren/removeChildren only accept X3DChildNode which in turn does not include the LayoutGroup itself anymore.</div><div><span style="color:rgb(0,0,0)"><br></span></div><div><span style="color:rgb(0,0,0)">I think some things can be easily fixed, others require further discussion, but it's better to know all of this.</span></div><div><span style="color:rgb(0,0,0)"><br></span></div><div><span style="color:rgb(0,0,0)">Daft for 4.1:</span></div><div><a href="https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/" target="_blank">https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/</a><font color="#000000"><span></span></font></div><div><span style="color:rgb(0,0,0)"><br></span></div><div>Best regards</div><div>Holger</div><div><br></div><div>
<div>—<br>Holger Seelig<br>Leipzig, Germany<br><br><a href="mailto:holger.seelig@yahoo.de" target="_blank">holger.seelig@yahoo.de</a><br><a href="https://create3000.github.io/x_ite/" target="_blank">https://create3000.github.io/x_ite/</a><br><a href="https://patreon.com/X_ITE" target="_blank">https://patreon.com/X_ITE</a><br></div><div><br></div><br>
</div>
<br></div>_______________________________________________<br>
x3d-public mailing list<br>
<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a><br>
<a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" rel="noreferrer" target="_blank">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a><br>
</blockquote></div>
</blockquote></div>