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

GPU Group gpugroup at gmail.com
Fri Mar 27 07:00:33 PDT 2026 

url parameters seem interesting. If the x3d browser itself is doing the
conversion --after loading the Inline raw file, then parsing and converting
to x3d before signaling loaded=TRUE,
- servers seem to ignore unknown parameters
x loading local files > adding a ? parameter: FILE NOT FOUND
-Doug
a) web url loading

https://andreasplesch.github.io/3d-tiles-examples/migration/output_from_1.0/Tilesets/TilesetOfTilesets/tileset.json

https://andreasplesch.github.io/3d-tiles-examples/migration/output_from_1.0/Tilesets/TilesetOfTilesets/tileset.json?note_to_loader=load_as_cesium

both:

response MIME/Content Type=application/json; charset=utf-8

loads json as text in browser window. Mimetype json not very helpful for
determining web3d suitable content


Youtube server also ignores unknown parameters

https://www.youtube.com/watch?v=2mPS-2guHVo

https://www.youtube.com/watch?v=2mPS-2guHVo&note_to_loader=load_as_cesium

b) local file loading

C:\Users\dougs\Downloads\tileset.json

- loads json as text in web browser window

 C:\Users\dougs\Downloads\tileset.json?note_to_loader=load_as_cesium

X File not found

The Inline would need to scrape its parameters out of the url before
attempting to load.



On Wed, Mar 25, 2026 at 1:03 PM Don Brutzman via x3d-public <
x3d-public at web3d.org> wrote:

> 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
>>>
>> _______________________________________________
> 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/20260327/9d2b1752/attachment-0001.html>

More information about the x3d-public mailing list