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

John Carlson yottzumm at gmail.com
Fri Mar 27 08:26:12 PDT 2026 

There might be an issue with loading .json as X3D JSON.  Please use .x3dj
for X3D JSON.

On Fri, Mar 27, 2026 at 9:01 AM GPU Group via x3d-public <
x3d-public at web3d.org> wrote:

> 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
>>
> _______________________________________________
> 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/06edea1c/attachment-0001.html>

More information about the x3d-public mailing list