[x3d-public] allowing full capabilities for X3D node reuse with Inline EXPORT/IMPORT AS/USE
John Carlson
yottzumm at gmail.com
Sun Oct 19 07:10:59 PDT 2025
Also this kind of clever app for path-like operations on JSON:
https://github.com/coderextreme/jtbd
Also, I’ve experimented with converting XPath-like stuff into > separated
nodes. Code available on request, I might have to revisit it. It should
be present In x3dvalidate, something like this:
let instancePath = errs[e].instancePath.replace(/^\./,
"").replace(/[\.\[\]']+/g, " > ").replace(/ >[ \t]*$/, "");
John
On Sun, Oct 19, 2025 at 8:49 AM John Carlson <yottzumm at gmail.com> wrote:
> Doug,
>
> I considered a MFPath field type some time ago:
>
>
> https://github.com/coderextreme/X3DJSONLD/blob/master/src/main/node/route.js
>
> See test() function for greatest detail.
>
> Enjoy!
>
> John
>
> On Sat, Oct 18, 2025 at 4:56 PM GPU Group via x3d-public <
> x3d-public at web3d.org> wrote:
>
>> Q: can/should/could/would it help to have an XPath-like SAI function that
>> returns a (filtered) list of nodes (MFNode), for example list of joint type
>> nodes from an HAnim?
>> -Doug
>> https://www.w3schools.com/XML/xml_xpath.asp
>>
>>
>> On Sat, Oct 18, 2025, 2:00 p.m. Don Brutzman <don.brutzman at gmail.com>
>> wrote:
>>
>>> Gee Doug, design sounds pretty thorough!
>>>
>>> Holger, the following HAnimPose prototype example + ProtoInstance nodes
>>> seem to be fully working now.
>>> -
>>>
>>> https://www.web3d.org/x3d/content/examples/HumanoidAnimation/Pose/HAnimPosePrototypeIndex.html
>>>
>>> However I have not been able to get the IMPORT/Inline HAnimHumanoid
>>> replacement to work, as an alternative to copying the HAnimHumanoid
>>> completely…
>>>
>>> Wondering if my conversion stylesheets are not iinvoking your latest
>>> X_ITE correctly?
>>>
>>> all the best, Don
>>> --
>>> Don Brutzman
>>> X3D graphics, virtual worlds, Navy robotics
>>> https://faculty.nps.edu/brutzman
>>>
>>>
>>> On Fri, Oct 17, 2025 at 09:10 GPU Group <gpugroup at gmail.com> wrote:
>>>
>>>> Thanks again Holger, the proxy idea might work in freewrl.
>>>> -Doug
>>>> more..
>>>> Recursive Addressing and Node Status Table:
>>>> Use-Case: Inlines can inline and pass-through nodes via import +
>>>> export.
>>>> - but each Inline can un-export or un-import a node
>>>> - script nodes can delete nodes in executionContext
>>>> Recursive Addressing:
>>>> When recursing from the main scene, a getNode(inode) funcion would
>>>> check current import, Inline.loaded, export, node deleted? and so on
>>>> through layers of inlines in what I'll call recursive addressing
>>>> - the recursive addressing would be applied when traversing the
>>>> scenegraph to draw a node, and when routing, would be applied at each end
>>>> of the route
>>>> - recursion bottoms out when a node is 'unresolved' or it gets to a
>>>> specific node (vs intermediary proxies)
>>>> NST node status table::
>>>> - MFNode and SFNode fields would hold integer indexes into a table of
>>>> (node or proxy address) aka NST node status table, which would be globally
>>>> available, and not garbage collected until the browser shuts down, and
>>>> putting a null for the entry when a node is deleted, but not re-using the
>>>> table entry for the life of the browser run. This would avoid the need for
>>>> hunting down references to a node that is being deleted. Any proxies
>>>> pointing to a node would go through the NST to get the address, and if null
>>>> would not draw/route.
>>>> - so when an Inline is unloaded, and all its nodes deleted, any
>>>> main-scene proxies pointing at imported nodes would go through the NST
>>>> IMPORT and EXPORT tables in each executionContext
>>>> - proxies would have an index into the table for themselves, and when
>>>> un-imported or un-exported (through SAI) a flag in the table would be set
>>>> Option: all nodes could be wrapped with a proxy, or just use proxies as
>>>> needed
>>>> During parsing, routes would not resolve to field ;memory address
>>>> end-points, but rather DEFname + fieldname.
>>>> - during routing, on the first pass, a long lookup getNodeB(string
>>>> DEFname) and getField(string fieldname) would be used, and subsequently if
>>>> nothing changed a shortcut would be used, while still recursing as needed
>>>> to check for deletion, import/export status, loaded status.
>>>>
>>>>
>>>>
>>>> On Thu, Oct 9, 2025 at 3:04 PM GPU Group <gpugroup at gmail.com> wrote:
>>>>
>>>>> Thanks Holger - I see something about proxy wrappers, and while smoke
>>>>> pours out of my ears, I'll incubate the implications.
>>>>> -Doug
>>>>> For example would routes carry the string field name, route to/from
>>>>> proxies, and proxy node would do string lookup on each routing loop? Would
>>>>> there be one type of route, and one type of proxy wrapper around all nodes,
>>>>> and the proxy would hold specific node pointer and a few other things like
>>>>> specific node type, or NULL if unloaded? Would the specific nodes have a
>>>>> pointer back to one specific proxy, or a list of proxies, so when being
>>>>> unloaded, it can refer back to it/ them all and empty all the proxies?
>>>>>
>>>>> On Thu, Oct 9, 2025 at 2:31 PM Holger Seelig <holger.seelig at yahoo.de>
>>>>> wrote:
>>>>>
>>>>>> Hello Doug,
>>>>>>
>>>>>> There is a special node internally X3DImportedNodeProxy which pretends
>>>>>> to be the exported node and then behaves accordingly. This class overloads
>>>>>> some basic functions. If this node is then inside an SFNode, you
>>>>>> won't notice any difference. If the Inline unloads, you should see a NULL
>>>>>> node maybe in the future.
>>>>>>
>>>>>>
>>>>>> https://github.com/create3000/x_ite/blob/feature/use-exported-node/src/x_ite/Components/Core/X3DImportedNodeProxy.js
>>>>>>
>>>>>> Best regards,
>>>>>> Holger
>>>>>>
>>>>>> —
>>>>>> Holger Seelig
>>>>>> holger.seelig at yahoo.de
>>>>>>
>>>>>>
>>>>>> Am 09.10.2025 um 22:09 schrieb GPU Group <gpugroup at gmail.com>:
>>>>>>
>>>>>> Holger, very interesting. I'd love to know how you did it, if it's
>>>>>> not too hard to explain.
>>>>>> -Doug
>>>>>>
>>>>>> On Thu, Oct 9, 2025 at 2:01 PM Holger Seelig <holger.seelig at yahoo.de>
>>>>>> wrote:
>>>>>>
>>>>>>> I have made an experimental implementation of this new feature. You
>>>>>>> can already use and play with it in the special preview playground:
>>>>>>>
>>>>>>>
>>>>>>> https://create3000.github.io/preview/playground/?url=https://create3000.github.io/Library/Tests/Components/Core/use-exported-node.x3dv
>>>>>>>
>>>>>>> This scene loads an inline file which exports a single green cube.
>>>>>>> This cube is imported into the scene and used a second time.
>>>>>>>
>>>>>>> There is also a experimental feature ‚USE before DEF‘ enabled in
>>>>>>> this preview playground. This feature seems important for me to get this
>>>>>>> all work in all cases.
>>>>>>>
>>>>>>> Best regards,
>>>>>>> Holger
>>>>>>>
>>>>>>> —
>>>>>>> Holger Seelig
>>>>>>> Leipzig, Germany
>>>>>>>
>>>>>>> holger.seelig at yahoo.de
>>>>>>> https://create3000.github.io/x_ite/
>>>>>>> https://patreon.com/X_ITE
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Am 09.10.2025 um 18:51 schrieb Don Brutzman via x3d-public <
>>>>>>> x3d-public at web3d.org>:
>>>>>>>
>>>>>>> Hi Doug. Thanks for looking this over.
>>>>>>>
>>>>>>> I meant to also note earlier that this proposed change in semantics
>>>>>>> has no effect on any existing EXPORT/IMPORT statements in any existing X3D
>>>>>>> models, versions 3.0 through 4.0.
>>>>>>>
>>>>>>> Am glad to see you describing how FreeWrl supports EXPORT/IMPORT to
>>>>>>> date.
>>>>>>>
>>>>>>> Certainly refactoring half a gazillion lines of code is likely not
>>>>>>> worthwhile for such an extensibility feature... don't want to risk
>>>>>>> provoking side-effect problems. Unless you want to, of course... :)
>>>>>>>
>>>>>>> I'm following your points. Seems sensible, but maybe any changes to
>>>>>>> the existing functionality you describe is pretty similar to other handling
>>>>>>> that is already in place. Please consider the following short reactions,
>>>>>>> and correct me if wrong:
>>>>>>>
>>>>>>> - Inline nodes exist and receive few ROUTE connections, there
>>>>>>> are not many fields there (url load etc.)
>>>>>>> - IMPORT creates a node reference that points somewhere in the
>>>>>>> scene subgraph loaded by Inline
>>>>>>> - That IMPORT reference can already send/receive events via
>>>>>>> ROUTE, as long defined in the spec.
>>>>>>> - In essence, the proposal says such a node reference might be
>>>>>>> treated in the same manner as other USE nodes, which are also node
>>>>>>> references.
>>>>>>>
>>>>>>> Again appreciate all consideration. Even if this is impractical for
>>>>>>> FreeWrl, your opinion on feasibility in general remains welcome. Am not
>>>>>>> trying to check boxes on a feature list, and am not trying to push a
>>>>>>> nontrivial architectural change. Rather am trying to enable significantly
>>>>>>> more scalable extensibility by removing a small existing constraint on
>>>>>>> usage.
>>>>>>>
>>>>>>> p.s. curiously, since the specification intentionally never mandates
>>>>>>> error responses, it seems like a browser implementation might
>>>>>>> satisfactorily permit IMPORT node references to behave similarly as USE
>>>>>>> node references, if it wants. hmmm...
>>>>>>>
>>>>>>> Have fun with X3D! 😀
>>>>>>>
>>>>>>> all the best, Don
>>>>>>> --
>>>>>>> X3D Graphics, Maritime Robotics, Distributed Simulation
>>>>>>> Relative Motion Consulting https://RelativeMotion.info
>>>>>>> <https://relativemotion.info/>
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Oct 9, 2025 at 9:14 AM GPU Group <gpugroup at gmail.com> wrote:
>>>>>>>
>>>>>>>> Don,
>>>>>>>> "synchronization" I suspect the change would break (25 year old,
>>>>>>>> currently unmaintained) freewrl. I like the use-case you mention for the
>>>>>>>> change, seems well worth a big change. Final nail in freewrl coffin? Not
>>>>>>>> necessarily but would require insight and ambition to refactor 500,000
>>>>>>>> lines of code to allow a layer of abstraction / uncertainty around every
>>>>>>>> node and route in the scenegraph.
>>>>>>>> -Doug
>>>>>>>> more..
>>>>>>>> tests for new conformance would be
>>>>>>>> - if routes can dangle before an Inline is loaded, and after an
>>>>>>>> Inline is unloaded
>>>>>>>> - by dangle I mean point harmlessly TO nothing / unloaded node,
>>>>>>>> without being garbage collected
>>>>>>>> - no error or warning is issued when a route dangles
>>>>>>>> - if Inlined nodes are to be treated like regular scenegraph nodes,
>>>>>>>> would that mean all routes to regular scenegraph nodes should be able to
>>>>>>>> dangle?
>>>>>>>> - current specs: a test for deleting a regular scenegraph node:
>>>>>>>> have an active route to it, and see if something breaks when the node is
>>>>>>>> deleted
>>>>>>>> -- would that need to change so instead of garbage collecting
>>>>>>>> routes to deleted nodes, they dangle, and (somehow) are allowed to hook
>>>>>>>> back up to new added nodes?
>>>>>>>> freewrl current Inline mechanism:
>>>>>>>> - Inlines are loaded, parsed in a separate thread, and can be
>>>>>>>> loaded and unloaded with true/false field on Inline
>>>>>>>> - on each rendering frame, when Inline node is
>>>>>>>> rendered/drawn/visited, it does a little work to check the load
>>>>>>>> progress/status, and makes any changes to IMPORT routes and AS nodes as
>>>>>>>> needed
>>>>>>>> - freewrl uses special routes to Inlined IMPORTed nodes, which can
>>>>>>>> 'dangle' (called weak routes in freewrl) while waiting for the inline to
>>>>>>>> load (rest of scene can be rendering).
>>>>>>>> - the special routes get an extra complex lookup to see if the TO
>>>>>>>> node is loaded
>>>>>>>> - versus deleting a regular scenegraph node would trigger a search
>>>>>>>> for routes to the deleted node, and the routes would be deleted/garbage
>>>>>>>> collected too
>>>>>>>> - and normal routes, freewrl uses memory addresses for start and
>>>>>>>> end node fields, and does a memory copy of field value during routing loop,
>>>>>>>> (versus weak/dangling route complex lookup in separate loop)
>>>>>>>> - when an Inline EXPORTed node is loaded it is allocated to a
>>>>>>>> memory address via malloc. when unloaded and free(), and reloaded and
>>>>>>>> reallocated, it would be loaded in a different memory address, so can't do
>>>>>>>> a simple memcpy with old address during routing, needs to check if node
>>>>>>>> loaded and what's the new memory address
>>>>>>>> SUMMARY: freewrl seems to be missing a layer of abstraction around
>>>>>>>> or flag for each node and route that would allow a USE of an Inlined AS
>>>>>>>> node and IMPORT route to enjoy equal status in the scenegraph. Not
>>>>>>>> immediately obvious how to fix / refactor.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, Oct 8, 2025 at 1:27 PM Don Brutzman via x3d-public <
>>>>>>>> x3d-public at web3d.org> wrote:
>>>>>>>>
>>>>>>>>> [BLUF summary: proposed specification change to allow regular
>>>>>>>>> re-USE of imported node references.]
>>>>>>>>>
>>>>>>>>> Am trying to write a prototype for HAnim, and hoped that I might
>>>>>>>>> EXPORT a large model so that a smaller scene might IMPORT the HAnimHumanoid
>>>>>>>>> for further reuse (as a USE node in a prototype). Example EXPORT:
>>>>>>>>>
>>>>>>>>> - 3D Example Archives: Humanoid Animation, Characters, Jin LOA
>>>>>>>>> 2
>>>>>>>>> - Articulated 3D game character designed with a general
>>>>>>>>> graphics tool, then converted into an X3D HAnim model and available for
>>>>>>>>> IMPORT as JinLOA2.
>>>>>>>>> -
>>>>>>>>> https://www.web3d.org/x3d/content/examples/HumanoidAnimation/Characters/JinLOA2Index.html
>>>>>>>>> - <!-- This node has an EXPORT
>>>>>>>>> <https://www.web3d.org/x3d/content/examples/HumanoidAnimation/Characters/JinLOA2.html#JinLOA2> connection
>>>>>>>>> that can exchange events with a parent X3D model. -->
>>>>>>>>> <HAnimHumanoid DEF='hanim_JinLOA2
>>>>>>>>> <https://www.web3d.org/x3d/content/examples/HumanoidAnimation/Characters/JinLOA2.html#hanim_JinLOA2>
>>>>>>>>> ' loa='2' name='JinLOA2' scale='0.0225 0.0225 0.0225'> on line
>>>>>>>>> 30
>>>>>>>>> <https://www.web3d.org/x3d/content/examples/HumanoidAnimation/Characters/JinLOA2.html#30>
>>>>>>>>>
>>>>>>>>> - <EXPORT localDEF='hanim_JinLOA2
>>>>>>>>> <https://www.web3d.org/x3d/content/examples/HumanoidAnimation/Characters/JinLOA2.html#hanim_JinLOA2>
>>>>>>>>> ' AS='JinLOA2'/> on line 1319
>>>>>>>>> <https://www.web3d.org/x3d/content/examples/HumanoidAnimation/Characters/JinLOA2.html#1319>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Hmmm, please notice that medium-size HAnim model is (1319 - 30 =
>>>>>>>>> 1289) lines long... gee, wouldn't it be nice to Inline and IMPORT
>>>>>>>>> that model in ~3 lines instead, with added benefit of being able to reuse
>>>>>>>>> pose and motion animations with it also.
>>>>>>>>>
>>>>>>>>> However the current X3D Architecture appears to restrict the usage
>>>>>>>>> of imported nodes solely to receiving/sending events. That restriction
>>>>>>>>> permits writing ROUTE connections, but a blocker if trying to write a
>>>>>>>>> prototype or trying other node re-USE.
>>>>>>>>>
>>>>>>>>> EXPORT and IMPORT statements are rarely used, but have been
>>>>>>>>> around a long time... since X3D 3.0, about 25 years maybe. They have
>>>>>>>>> potential for great expressive power and extensibility (the X in X3D).
>>>>>>>>> However, am guessing that the reuse limitation of IMPORT nodes has likely
>>>>>>>>> inhibited our adoption. If I recall correctly, the primary objection (way
>>>>>>>>> back then) to allowing full access to an imported node reference was
>>>>>>>>> uncertainty about how it might all work, perhaps complicated by run-time
>>>>>>>>> synchronization concerns.
>>>>>>>>>
>>>>>>>>> We have come a long way since then. It seems pretty clear that an
>>>>>>>>> Inline node loads an external scene graph into the current scene graph.
>>>>>>>>> Further, the EXPORT statement identifies a specific node (sub graph) within
>>>>>>>>> that inlined scene graph.
>>>>>>>>>
>>>>>>>>> The straightforward way to think about this: Inline
>>>>>>>>> EXPORT/IMPORT provides a reference to a node in the currently loaded scene
>>>>>>>>> graph. Given that the author has a reference to an active node,
>>>>>>>>> they ought to be able to utilize that node reference just like any other
>>>>>>>>> DEF/USE node reference.
>>>>>>>>>
>>>>>>>>> I propose we relax the legacy (25-year) restriction and allow
>>>>>>>>> IMPORT node references to be treated the same as USE node references.
>>>>>>>>>
>>>>>>>>> Towards that end, have written out suggested changes in the draft
>>>>>>>>> v4.1 architecture, adding to a number of editorial improvements already
>>>>>>>>> accomplished as part of
>>>>>>>>>
>>>>>>>>> - Mantis 1470: add EXPORT/IMPORT field DESCRIPTION for X3D
>>>>>>>>> Architecture 4.1; also allow reuse
>>>>>>>>> - https://mantis.web3d.org/view.php?id=14701470: add
>>>>>>>>> EXPORT/IMPORT field DESCRIPTION for X3D Architecture 4.1
>>>>>>>>>
>>>>>>>>> Request review, considerations and reactions. The markup changes
>>>>>>>>> at first look complex but are essentially all geared towards the single
>>>>>>>>> objective of allowing re-use of IMPORT nodes. Lots of markup shows that
>>>>>>>>> there are few actual changes to existing prose, most of it is simply
>>>>>>>>> editorial re-organization for clarity.
>>>>>>>>>
>>>>>>>>> This is a good topic for this week's specification editors call on
>>>>>>>>> Friday (9 pacific).
>>>>>>>>> ______________________________
>>>>>>>>>
>>>>>>>>> For easy review, current markup follows. *First is Concepts.*
>>>>>>>>>
>>>>>>>>> - X3D Architecture v4.1, clause 4 Concepts, 4.4.6
>>>>>>>>> EXPORT/IMPORT semantics
>>>>>>>>> -
>>>>>>>>> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/concepts.html#ExportImportSemantics
>>>>>>>>>
>>>>>>>>> 4.4.6 EXPORT/IMPORT semantics Import/Export semantics
>>>>>>>>>
>>>>>>>>> Editors note: there are few actual changes here, most are simply
>>>>>>>>> switching the order of EXPORT and IMPORT. Added functionality: imported
>>>>>>>>> node reuse.
>>>>>>>>>
>>>>>>>>> The EXPORT feature allows authors to identify specific parts of an
>>>>>>>>> X3D model which might be safely shared and reused by other X3D models. The
>>>>>>>>> IMPORT feature allows authors to incorporate content defined within Inline
>>>>>>>>> nodes or created programmatically into the namespace of the containing file
>>>>>>>>> for the purposes of event routing and reusing scene subgraphs on
>>>>>>>>> a per-node basis. In contrast with external prototyping (see 4.4.5
>>>>>>>>> External prototype semantics
>>>>>>>>> <https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/concepts.html#Externalprototypesemantics>),
>>>>>>>>> which allows access to individual fields of nodes defined as prototypes in
>>>>>>>>> external files, IMPORT provides access to all the fields of an externally
>>>>>>>>> defined node with a single statement (see 9.2.6 IMPORT statement
>>>>>>>>> <https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/components/networking.html#IMPORTStatement>
>>>>>>>>> ).
>>>>>>>>>
>>>>>>>>> Importing nodes from an Inlined file is accomplished with two
>>>>>>>>> statements: EXPORT and IMPORT. IMPORT and EXPORT. The IMPORT
>>>>>>>>> statement is used in the containing file to define which nodes of an Inline
>>>>>>>>> are to be incorporated into the containing file's namespace. The
>>>>>>>>> EXPORT statement is used in the file being Inlined, to control access over
>>>>>>>>> which nodes within a file are visible to other files (see 9.2.5
>>>>>>>>> EXPORT statement
>>>>>>>>> <https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/components/networking.html#EXPORTStatement>).
>>>>>>>>> EXPORT statements are not allowed in prototype declarations. The
>>>>>>>>> IMPORT statement is used in the containing file to define which nodes of an
>>>>>>>>> Inline are to be incorporated into the containing file's namespace.
>>>>>>>>>
>>>>>>>>> In contrast with external prototyping (see 4.4.5 External
>>>>>>>>> prototype semantics
>>>>>>>>> <https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/concepts.html#Externalprototypesemantics>),
>>>>>>>>> which allows access to individual fields of nodes defined as prototypes in
>>>>>>>>> external files, IMPORT provides access to all the fields of an externally
>>>>>>>>> defined node with a single statement (see 9.2.6 IMPORT statement
>>>>>>>>> <https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/components/networking.html#IMPORTStatement>
>>>>>>>>> ).
>>>>>>>>>
>>>>>>>>> ______________________________
>>>>>>>>>
>>>>>>>>> *Next is the EXPORT statement.*
>>>>>>>>>
>>>>>>>>> - X3D Architecture v4.1, clause 9 Networking component, 9.2.5
>>>>>>>>> EXPORT statement
>>>>>>>>> -
>>>>>>>>> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/components/networking.html#EXPORTStatement
>>>>>>>>>
>>>>>>>>> 9.2.5 EXPORT statement
>>>>>>>>>
>>>>>>>>> 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 scene. file. DEF names are used to identify exported
>>>>>>>>> nodes. See 4.4.6 EXPORT/IMPORT semantics
>>>>>>>>> <https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/concepts.html#ExportImportSemantics> for
>>>>>>>>> further details.
>>>>>>>>>
>>>>>>>>> EXPORT statements may appear anywhere in the file and have the
>>>>>>>>> following form:
>>>>>>>>>
>>>>>>>>> EXPORT <NodeDEFName> [ AS <ExportedNodeDEFName> ]
>>>>>>>>> [DESCRIPTION "a simple description of intended EXPORT
>>>>>>>>> purpose"]
>>>>>>>>>
>>>>>>>>> EXPORT <NodeName> [ AS <ExportedNodeName> ]
>>>>>>>>>
>>>>>>>>> The EXPORT statement has the following components:
>>>>>>>>>
>>>>>>>>> 1. The local DEF name of the node to be exported if the
>>>>>>>>> current scene is retrieved externally via Inline,
>>>>>>>>> 2. An optional alternative DEF name that is used AS a default as
>>>>>>>>> an alias for the exported node when importing it into other
>>>>>>>>> scenes, files,
>>>>>>>>> 3. An optional simple DESCRIPTION of intended purpose for the
>>>>>>>>> node provided via EXPORT.
>>>>>>>>>
>>>>>>>>> The EXPORT statement has the following semantics:
>>>>>>>>>
>>>>>>>>> 4. Once imported into a containing scene, events may be routed
>>>>>>>>> to or from the fields of an exported node in exactly the same
>>>>>>>>> manner as any node defined with DEF.
>>>>>>>>> 5. Exported nodes imported into a containing scene may be
>>>>>>>>> referenced via a USE statement in the importing scene. may not
>>>>>>>>> be instanced via the USE statement.
>>>>>>>>> 6. 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.
>>>>>>>>> 7. Nodes shall not be exported from within the body of a PROTO
>>>>>>>>> declaration.
>>>>>>>>> 8. Any scene with an EXPORT statement shall apply UNIT
>>>>>>>>> statement adjustments as needed to the fields of any exported nodes and
>>>>>>>>> child nodes.
>>>>>>>>> 9. The EXPORT statement can appear wherever a ROUTE statement
>>>>>>>>> is allowed, and shall be contained within the Inline node to which it
>>>>>>>>> refers.
>>>>>>>>>
>>>>>>>>> The following example illustrates the use of the EXPORT statement
>>>>>>>>> (Classic VRML encoding):
>>>>>>>>>
>>>>>>>>> EXAMPLE
>>>>>>>>>
>>>>>>>>> DEF T1 Transform {
>>>>>>>>> # additional nodes and fields...
>>>>>>>>> }# additional nodes and fields...
>>>>>>>>>
>>>>>>>>> EXPORT T1 AS rootTransform
>>>>>>>>>
>>>>>>>>> In the above example, node T1 is exported for use by other X3D
>>>>>>>>> scenes. The optional AS keyword defines the exported name of *T1*
>>>>>>>>> as *rootTransform* (*i.e.*, other scenes may import the node
>>>>>>>>> only using the name rootTransform). All defined alias AS names
>>>>>>>>> shall also meet appropriate uniqueness requirements in the local DEF
>>>>>>>>> namespace of the parent scene.
>>>>>>>>>
>>>>>>>>> ______________________________
>>>>>>>>> *Next is the IMPORT statement.*
>>>>>>>>>
>>>>>>>>> - X3D Architecture v4.1, clause 9 Networking component, 9.2.6
>>>>>>>>> IMPORT statement
>>>>>>>>> -
>>>>>>>>> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/components/networking.html#IMPORTStatement
>>>>>>>>>
>>>>>>>>> 9.2.6 IMPORT statement
>>>>>>>>>
>>>>>>>>> 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. DEF names are used to identify nodes. See 4.4.6
>>>>>>>>> EXPORT/IMPORT semantics
>>>>>>>>> <https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/concepts.html#ExportImportSemantics> for
>>>>>>>>> further details.
>>>>>>>>>
>>>>>>>>> IMPORT statements may appear anywhere in the file and have the
>>>>>>>>> following form:
>>>>>>>>>
>>>>>>>>> IMPORT <InlineNodeDEFName>*.*<ExportedNameFromInlinedFile> [ AS
>>>>>>>>> <NewLocalNodeDEFName> ]
>>>>>>>>> [DESCRIPTION "a simple description of intended IMPORT
>>>>>>>>> purpose"]
>>>>>>>>>
>>>>>>>>> IMPORT <InlineNodeName>*.*<ExportedNameFromInlinedFile> [ AS
>>>>>>>>> <NewLocalNodeName> ]
>>>>>>>>>
>>>>>>>>> The IMPORT statement has the following components:
>>>>>>>>>
>>>>>>>>> 1. The DEF name of the Inline node that contains the node to
>>>>>>>>> be imported,
>>>>>>>>> 2. The DEF name of the node to import,
>>>>>>>>> 3. An optional alternative DEF name that is used AS as an
>>>>>>>>> alias for the imported node within the run-time name scope, to help
>>>>>>>>> prevent avoid potential DEF name clashes within the parent
>>>>>>>>> scene containing the IMPORT statement,
>>>>>>>>> 4. An optional simple DESCRIPTION of intended purpose for the
>>>>>>>>> node provided via IMPORT.
>>>>>>>>>
>>>>>>>>> The IMPORT statement has the following semantics:
>>>>>>>>>
>>>>>>>>> 5. Once imported, events may be routed to or from the fields
>>>>>>>>> of an imported node in the Inline scene, in exactly the same
>>>>>>>>> manner as any node defined locally with DEF.
>>>>>>>>> 6. Editors note: the following is an important change,
>>>>>>>>> otherwise an imported node cannot be utilized other than by receiving
>>>>>>>>> ROUTEd events (as shown by the InlineImport.x3d
>>>>>>>>> <https://www.web3d.org/x3d/content/examples/Basic/X3dSpecifications/InlineImportIndex.html>
>>>>>>>>> example).
>>>>>>>>> Nodes imported into an X3D scene using the IMPORT statement
>>>>>>>>> may be referenced not be instanced via the USE statement.
>>>>>>>>> 7. Only nodes that are exported from within the Inline scene via
>>>>>>>>> an EXPORT statement may be imported using a corresponding IMPORT statement.
>>>>>>>>> 8. The IMPORT statement can appear wherever a ROUTE statement
>>>>>>>>> is allowed, and shall follow the Inline node to which it refers.
>>>>>>>>>
>>>>>>>>> Any node reference that is obtained via IMPORT from an exporting
>>>>>>>>> scene is also available as a USE node in the importing scene. This
>>>>>>>>> requirement is necessary for the node reference retrieved by IMPORT to have
>>>>>>>>> full capabilities in the importing scene. Nevertheless, important
>>>>>>>>> synchronization considerations arise when one or more Inline models are
>>>>>>>>> loaded as part of the current scene graph.
>>>>>>>>>
>>>>>>>>> 9. A single Inline node is allowed to have multiple IMPORT
>>>>>>>>> statements. The state of nodes within that currently loaded Inline model
>>>>>>>>> are consistently maintained as part of the current scene.
>>>>>>>>> 10. Multiple Inline nodes with separate IMPORT statements are
>>>>>>>>> completely independent, even if each independent Inline is retrieving a
>>>>>>>>> copy of the same original model.
>>>>>>>>>
>>>>>>>>> The following example illustrates the use of the IMPORT statement
>>>>>>>>> (Classic VRML encoding syntax):
>>>>>>>>>
>>>>>>>>> EXAMPLE
>>>>>>>>>
>>>>>>>>> DEF MyInline I1 Inline {
>>>>>>>>> url "someurl.x3d"
>>>>>>>>> }
>>>>>>>>> IMPORT MyInline.rootTransform AS ImportedTransform I1.rootTransform AS I1Root ...
>>>>>>>>> # ROUTE events into the imported node, which is now a part of an Inline scene subgraph
>>>>>>>>> DEF PI PositionInterpolator { } { ... }
>>>>>>>>> ROUTE PI.value_changed TO ImportedTransform.set_translation I1Root.set_translation
>>>>>>>>>
>>>>>>>>> # also USE the imported node (and associated scene subgraph) elsewhere in the parent scene
>>>>>>>>> Group {
>>>>>>>>> USE ImportedTransform
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> # also USE the imported node when defining an instance of a MyNewTransform prototype
>>>>>>>>> MyNewTransform {
>>>>>>>>> children USE ImportedTransform
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> In the above example,
>>>>>>>>>
>>>>>>>>> - rootTransform is externally defined as a Transform node in
>>>>>>>>> the file someurl.x3d and exported via an EXPORT statement.
>>>>>>>>> (see 4.4.6 Import/Export semantics
>>>>>>>>> <https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/concepts.html#ExportImportSemantics>
>>>>>>>>> ).
>>>>>>>>> - The optional AS keyword in the IMPORT statement defines an
>>>>>>>>> alias for the MyInline.rootTransform rootTransform DEF. , so
>>>>>>>>> that
>>>>>>>>> - Within the containing scene, the node is referenced using
>>>>>>>>> the AS alias name ImportedTransform. DEF name I1Root.
>>>>>>>>>
>>>>>>>>> All defined alias AS names shall also meet appropriate uniqueness
>>>>>>>>> requirements in the local DEF namespace of the parent scene.
>>>>>>>>>
>>>>>>>>> ______________________________
>>>>>>>>> Additional thanks to Joe Williams, Holger Seelig, and Nicholas
>>>>>>>>> Polys for contributing to this analysis and potential improvement.
>>>>>>>>>
>>>>>>>>> All feedback welcome! This simple functional refinement has
>>>>>>>>> potential for much X3D scalability and extensibility.
>>>>>>>>>
>>>>>>>>> Thanks in advance for considering the possibilities.
>>>>>>>>>
>>>>>>>>> all the best, Don
>>>>>>>>> --
>>>>>>>>> X3D Graphics, Maritime Robotics, Distributed Simulation
>>>>>>>>> Relative Motion Consulting https://RelativeMotion.info
>>>>>>>>> <https://relativemotion.info/>
>>>>>>>>> _______________________________________________
>>>>>>>>> x3d-public mailing list
>>>>>>>>> x3d-public at web3d.org
>>>>>>>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>> x3d-public mailing list
>>>>>>> x3d-public at web3d.org
>>>>>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> _______________________________________________
>> 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/20251019/db00b421/attachment-0001.html>
More information about the x3d-public
mailing list