[x3d-public] Inline > type field > for loading / converting / parsing other content

[Don Brutzman]

Distilling these points, I added the following editors note to v4.1 draft
InlineGeometry

   - Composition of online addresses and parameter values within a *url* field
   offers the possibility of invoking an online server to perform file-format
   conversions. See email thread [x3d-public] Inline > type field > for
   loading / converting / parsing other content
   <https://web3d.org/pipermail/x3d-public_web3d.org/2026-March/022355.html>
for
   further discussion. Such additional functionality supports the use cases
   under consideration by Metaverse Standards Forum (MSF) 3D Web
   Interoperability
   <https://metaverse-standards.org/domain-groups/3d-web-interoperability>
Working
   Group.

all the best, Don
-- 
X3D Graphics, Maritime Robotics, Distributed Simulation
Relative Motion Consulting  https://RelativeMotion.info


On Wed, Mar 25, 2026 at 11:44 AM Don Brutzman <don.brutzman at gmail.com>
wrote:

> Doug, thanks for scrutiny of InlineGeometry and your post.
>
>    - X3D Architecture 4.1 draft — ISO/IEC 19775-1:202x — 9 Networking
>    component - 9.4.3 InlineGeometry
>    <https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/components/networking.html#InlineGeometry>
>    -
>    https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/components/networking.html#InlineGeometry
>
> Option 0: automatic detection? MIME type offers a lot (see below for
> more), then careful scrutiny is always warranted.  A browser does not have
> to load something it is unable to handle (and indeed probably cannot do so
> anyway).
>
> Option 1: new node type?  If we find new functionality (or perhaps
> security precautions) in common between Inline and InlineGeometry that also
> pertains to other nodes having a url field, then it can be added to
> X3DUrlObject.  Otherwise it is typically best over long term to keep it
> associated with node itself.
>
> Option 2: additional fields to support conversions?  I think we should be
> very reluctant to specify external functionality.  However of note is that
> many online applications can be invoked by composing url values and
> parameters.  Experimentation is certainly possible via the current
> InlineGeometry url.  Here is an example composition:
>
>    - X3D Example Archives: Humanoid Animation, Bones, All Bones
>    Collection, X_ITE (Playground
>    <https://create3000.github.io/x_ite/playground/?url=https://www.web3d.org/x3d/content/examples/HumanoidAnimation/Bones/AllBonesCollection.x3d>
>    )
>    -
>    https://create3000.github.io/x_ite/playground/?url=https://www.web3d.org/x3d/content/examples/HumanoidAnimation/Bones/AllBonesCollection.x3d
>
> which is available at
>
>    -
>    https://www.web3d.org/x3d/content/examples/HumanoidAnimation/Bones/AllBonesCollectionIndex.html
>
> Given such possibilities, if experimentation showed some useful long-term
> patterns, then next step would be establishing recommended/best practices
> and showing interoperability before elevating such features into the spec.
> X3D is Extensible, after all.
>
> John, to your points:
>
>
>> I think MIME/HTTP Content-Type headers may prove useful here.
>
>
> Yes, certainly, that information comes along with http/https requests
> exchanged with properly configured servers.  Thus content type is available
> to browser, along with file extension.  For local files (relative url
> addresses) such negotiation typically occurs with the local operating
> system.
>
> I believe that such concepts are addressed by existing draft paragraph
> containing
>
>    - "can be determined with some form of content negotiation (see RFC9110
>    <https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/references.html#RFC9110>
>    )"
>
> Do we want to provide CDATA Sections or data URIs for non-X3D content?
>
>
> The purpose of the InlineGeometry node is to perform a file retrieval, so
> I am not seeing a use case...  We don't do that for Inline either.
>
> Again thanks everyone for considering the possibilities.  Have fun with
> X3D InlineGeometry!
>
> all the best, Don
> --
> X3D Graphics, Maritime Robotics, Distributed Simulation
> Relative Motion Consulting  https://RelativeMotion.info
>
>
> On Wed, Mar 25, 2026 at 10:26 AM John Carlson via x3d-public <
> x3d-public at web3d.org> wrote:
>
>> I think MIME/HTTP Content-Type headers may prove useful here.
>>
>> Do we want to provide CDATA Sections or data URIs for non-X3D content?
>>
>> John
>>
>> On Wed, Mar 25, 2026 at 11:08 AM GPU Group via x3d-public <
>> x3d-public at web3d.org> wrote:
>>
>>> Inline > content type field > for loading / converting / parsing other
>>> content
>>> other file formats - .obj, .ply, .json - may contain content suitable
>>> for converting into equivalent web3d nodes / scenegraphs. In theory this
>>> could be done while loading the content as an inline based on file suffix.
>>> But those generic file type suffixes don't say what type of nodes we are
>>> expecting to get / want to extract or convert to web3d nodes.
>>> Option 0: Sniffing the file for automatic detection of suitable web3d
>>> node content
>>> Option 1: A new node type, derived from Inline, for each combination of
>>> file suffix and desired content conversion - assumes main scene author with
>>> the Inline URL also knows the type of content / conversion
>>> Option 2: an additional field on standard Inline, saying what content
>>> converter to use, an enum field with things like "SPLAT", "CESIUM"
>>> Then the web3d browser developer would write code to process / convert
>>> the (file type, content converter type) cases to web3d nodes/scenegraph
>>> after Inline loads the file.
>>>
>>> -Doug
>>>
>>> _______________________________________________
>>> 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/20260325/6236c8e0/attachment.html>