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

[Don Brutzman]

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/b238194b/attachment-0001.html>