[x3d-public] Remove property prefixes: @, - and # in X3D JSON?
Don Brutzman
don.brutzman at gmail.com
Tue Feb 17 23:02:14 PST 2026
The basic story hasn't changed... now added on our page.
- *X3D to JSON Stylesheet Converter*
<https://www.web3d.org/x3d/stylesheets/X3dToJson.html>
- The X3D to JSON stylesheet converts .x3d XML to .json, supporting the
forthcoming JSON Encoding for X3D Graphics.
- This page fully describes current X3D JSON design patterns and syntax,
providing examples and references.
- https://www.web3d.org/x3d/stylesheets/X3dToJson.html
-
>
> *Planned Progress*
> Current status: X3D JSON developmental work is mature and provides
> full coverage of X3D model capabilities in JSON, as demonstrated by thousands
> of example models
> <https://www.web3d.org/x3d/content/examples/X3dResources.html#Examples>.
> Design patterns have been available and assessed by X3D community for
> several years. One possible addition to be considered will be use of an
> .x3dj file extension as an alternative to the classic .json file
> extension.
> The only significant gap in current assets is availability of a JSON
> Schema for X3D, autogenerated from the X3D Unified Object Model
> (X3DUOM) <https://www.web3d.org/specifications/X3DUOM.html>. Web3D
> Consortium standardization efforts have been quite careful about taking
> this step. Although JSON Schema design <https://json-schema.org> has
> not been formally ratified or standardized, it appears to be sufficiently
> well defined and implemented to justify creating an X3D JSON Schema as an
> informative annex in the upcoming draft specification for the X3D JSON
> Encoding. We expect such work to occur in Spring 2026.
Regarding any juggling of @ - # prefixes, I suggest
- Anything different than current design requires some evidence of
improvement, not preferences.
- We still have to confirm and demonstrate that generation of a JSON
Schema can be fully compatible with these prefix characters. Further best
practices for JSON and JSON Schema may also have emerged.
- X3D JSON Specification products must meet design requirements and
follow implementation, evaluation, and consensus.
p.s. Thanks for your long patience on this topic John, we are finally
catching up.
Wondering, have you asked the JSON Schema community why the internet drafts
for JSON Schema are not yet standardized? Is there a hidden flaw preventing
finalization, or competing incompatible approaches??? That mysterious
problem puts a lot of work (all across the Web) at possible risk in the
future. If there is an unstated disqualifying problem for JSON Schema out
there, it would be good for our community (and not doubt others) to finally
know about it.
all the best, Don
--
X3D Graphics, Maritime Robotics, Distributed Simulation
Relative Motion Consulting https://RelativeMotion.info
On Mon, Feb 16, 2026 at 7:14 PM John Carlson via x3d-public <
x3d-public at web3d.org> wrote:
> Here’s the background material in “A JSON encoding for X3D”:
>
> ==========
>
> During development it became clear that it was necessary to make it easy
> to distinguish the names of fields from the names of nodes, since both
> appear as JSON strings. It was decided to prepend a non-alphabetic
> character to field names, using different characters for the two field categories.
> This makes it easy for parsers, loaders and validators to recognize the
> string as a field name, and identify any errors in usage.
> ============
>
> I’m guessing this is development of Coin3D? With my serializers, it was
> easy enough to use fieldTypes.js, after the prefixes were removed by
> X3DJSONLD and converted to DOM. A more direct conversion to DOM would be
> appreciated!
>
>
> https://github.com/coderextreme/X3DJSONLD/blob/master/src/main/node/fieldTypes.js
>
>
> It might be helpful to distinguish nodes from statements as well?
>
> Of course, if one is reading directly into scenegraph, without my handy
> type lookup table, I can understand why one might want a field
> discriminator.
>
> So now I ask, do we really need something to distinguish types of
> properties in JavaScript? Are there workarounds for other languages like
> fieldTypes.js that can help? Surely, we can use X3DUOM to generate such
> artifacts?
>
> John
>
> On Mon, Feb 16, 2026 at 8:21 PM John Carlson <yottzumm at gmail.com> wrote:
>
>> For those who aren’t familiar, I will try to outline the requirement for
>> @, - and # property prefixes in X3D JSON.
>>
>> @ is for non-MFNode, non-SFNode fields.
>> - is for MFNode and SFNode fields.
>> # is for comments and source code—shaders and scripts.
>>
>> The problem is that when you want to access, say geometry or appearance,
>> you have to do:
>>
>> shape[‘-appearance’] instead of shape.appearance.
>>
>> AFAIK, shape.-appearance just doesn’t work.
>>
>> Similarly,
>>
>> transform[‘@translation’]
>>
>> vs
>>
>> transform.translation
>>
>> And again, transform. at translation doesn’t work.
>>
>> I understand there might be problems with this “new” approach. Let’s try
>> to lay out pros vs cons.
>>
>> I think my current goal is to make parsing and generation of JSON easy.
>> My thought is to take out the @ and leave - and #. We already have
>> examples of that in the X3D node.
>>
>> What do you think?
>>
>> John
>>
>> On Mon, Feb 16, 2026 at 7:55 PM John Carlson <yottzumm at gmail.com> wrote:
>>
>>> As one can see from this example code, the property prefixes @, # and -
>>> aren’t necessary in X3D JSON:
>>>
>>> https://github.com/coderextreme/my-second-react-three-app/blob/main/src/App.jsx
>>>
>>> Let’s think about removing these from X3D JSON. We need to consider
>>> performance and ease of use and development. If there’s no need, why did
>>> we invent the prefixes, to make JavaScript and TypeScript developers tear
>>> their hair out?
>>>
>>> Thanks!
>>>
>>> John
>>>
>>> On Mon, Feb 16, 2026 at 6:47 PM John Carlson <yottzumm at gmail.com> wrote:
>>>
>>>> If there’s time on the agenda, I’d like to present a beginnings of an
>>>> “X3D JSON” viewer/editor developed with AI using React and THREE.js with
>>>> WebGPU renderer. This is quite different than the three-x3d-loader
>>>> previously presented, and is along the lines of AFrame but not even
>>>> Interchange profile.
>>>>
>>>> There’s obviously a lot more work to do.
>>>>
>>>> Thanks!
>>>>
>>>> John
>>>>
>>>> On Mon, Feb 16, 2026 at 4:47 PM Anita Havele via AI <ai at web3d.org>
>>>> wrote:
>>>>
>>>>> Anita Havele <anita.havele at web3d.org> has invited you to Agenda —
>>>>> AI-X3D SIG Meeting on Feb 17, 2026 AT 8:00 AM PST (GMT-8)
>>>>>
>>>>> --
>>>>> AI mailing list
>>>>> AI at web3d.org
>>>>> http://web3d.org/mailman/listinfo/ai_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/20260217/e4f2e583/attachment.html>
More information about the x3d-public
mailing list