[x3d-public] JSON status

Sun Oct 5 10:10:02 PDT 2025

Castle Game Engine applications can (and should) use "castle-data:/"
URL protocol to access files within the application "data", see
https://castle-engine.io/data for details.

It's a feature -- this way you can access your application data on all
systems, even when the application data is internally packaged in some
special way (e.g. Android, web -- where the "data" is internally
packaged in some special way). The point is that you don't need to
care about this "how is your data packaged when you build Android or
web application", you just access your resources as
"castle-data:/mymodel.x3d" etc. and it will work on desktop, mobile,
web, console...

There is no requirement from this that affects your user models. If
you implemented X3D JSON handling using CGE, it should handle models
coming from any place - files, http(s), castle-data, anywhere else.
https://castle-engine.io/url . And you can use relative URLs in your
data to address anything. E.g. X3D JSON files should refer to stuff,
like textures or audio files or shader files using relative URLs, as
it common in X3D (whether for Castle or other viewers), and can
provide alternative URLs (like to download some resource from http(s)
).

In other words, having "castle-data:/"  is a feature, we're not going
to remove it, it's absolutely useful :) But it's also not something
that should be a problem for you. Your X3D models, including X3D JSON,
can use any URLs, including relative ones, just as they work in any
other X3D browsers.

It's unrelated to https and our recent CastleHttps.

Regards,
Michalis

niedz., 5 paź 2025 o 17:51 John Carlson <yottzumm at gmail.com> napisał(a):
>
> I see a mistake.  I don’t mean .x3dj files are shaders, but I don’t know if that’s ruled out in castle.  I’m more referring to ExternProto for .x3dj, and also images (in the past) need “castle-data://“ in the URL to refer to the local data folder.
>
> Sorry for the confusion!
>
> John
>
> On Sun, Oct 5, 2025 at 10:44 AM John Carlson <yottzumm at gmail.com> wrote:
>>
>> Sure, Michalis,
>>
>> What I’m referring to is the urls in jsonmodelviewer used to (still?) require a “castle-data://“ prefix in order to be found.  I am not referring to the castle model viewer.
>>
>> Sorry for not being plainer.  Perhaps the recent work on https has gotten rid of this requirement?
>>
>> A special flag in a X3dToJson.xslt (or a new X3dToCastleJson.xslt) might indicate use of “castle-data://“ prefixes in .x3dj files, but only when targeting jsonmodelviewer.
>>
>> Again, I’m not sure if special urls are still a requirement, given recent work on https in castle, and they were probably never a requirement for castle model viewer.
>>
>> This is good information if you are making a Pascal game which includes .x3dj urls (like shaders), but unnecessary if you are using Castle Model Viewer.  Inlining is still an option.
>>
>> Further details are welcome!
>>
>> John
>>
>> On Sun, Oct 5, 2025 at 9:09 AM Michalis Kamburelis <michalis.kambi at gmail.com> wrote:
>>>
>>>
>>>
>>> Note: I'm not sure what you mean by "Note that Castle, in the past,
>>> has had special URLs, indicating a X3dToCastle.xslt or special flags
>>> to add Castlisms." :) We don't have anything X3dToCastle.xslt , and
>>> I'm not sure what special flags you mean.
>>>
>>> Regards,
>>> Michalis
>>>
>>> sob., 4 paź 2025 o 23:46 John Carlson <yottzumm at gmail.com> napisał(a):
>>> >
>>> > Read through some of this as well,
>>> > https://www.web3d.org/x3d/stylesheets/X3dToJson.html
>>> >
>>> > Note that in addition to X3DOM and X_ITE, there is also a prototype JSON .x3dj loader (JSON to DOM to XML) for Castle:
>>> > https://github.com/coderextreme/jsonmodelviewer/
>>> >
>>> > But typically, a Pascal programmer would leverage this on their project, it’s not in the main model viewer yet that I know of.   Note that Castle, in the past, has had special URLs, indicating a X3dToCastle.xslt or special flags to add Castlisms.  But I think this is unnecessary for the base model viewer.
>>> >
>>> > Further work would involve direct JSON to scenegraph conversion (first attempt failed).
>>> >
>>> > John
>>> >
>>> > On Sat, Oct 4, 2025 at 3:52 PM John Carlson <yottzumm at gmail.com> wrote:
>>> >>
>>> >>
>>> >>
>>> >> On Sat, Oct 4, 2025 at 3:22 PM Don Brutzman via x3d-public <x3d-public at web3d.org>If progress continues as planned, we should be able to have a draft XML DTD/Schema (and hopefully JSON Schema too) in the spring in order to start building, validating, and evaluating models with such new features.
>>> >>
>>> >> Don:
>>> >>
>>> >> Any time you want help with validating JSON documents, let me know.   I can always rev-up my x3droundtrip project as well!
>>> >>
>>> >> I also note that jsonlint provides schema validation that I apparently missed!
>>> >>
>>> >> Here’s a version which supports
>>> >> draft JSON Schema 2020-12:
>>> >>
>>> >> https://www.npmjs.com/package/@prantlf/jsonlint
>>> >>
>>> >> If you can work with uncertainties in npm (check package.json and package-lock.json dependencies and pinned versions, make sure you’re not running postinstall scripts).   Note that npm already checks for vulnerabilities.  And if you have GitHub, it also checks for issues in the package*.json files.
>>> >>
>>> >> I have not seen these features in ant, maven or gradle, but I have seen that maven repositories do report vulnerabilities.
>>> >>
>>> >> One issue I haven’t resolved is choosing emoji’s versus X3D URNs in url fields.  It’s a matter of iri-reference verses uri-reference in the format properties in the schema.
>>> >>
>>> >> Note that I think you’ll probably find many issues with MFNode vs SFNode in X3dToJson.xslt which I haven’t reported.  Most of my XML to JSON conversions have migrated to Holger’s x3d-tidy.
>>> >>
>>> >> John
>>> >>