[x3d-public] X3D Specifications ready for review: XML, ClassicVRML, and Compressed Binary Encodings
John Carlson
yottzumm at gmail.com
Mon Oct 6 08:24:54 PDT 2025
Note that I’ve joined the Consortium. I will try to add Web3D Consortium
license to the enclosed links, if someone can give me a link to the recent
license. I did see a submission form, probably for conferences ???
Also, it would be good to know any metadata required.
My JSON schemas are here, but I am unaware of the correct metadata to add
for licensing.
https://github.com/coderextreme/x3dvalidate/tree/master/schemas
Really, all the data is from X_ITE and X3DUOM, so I’m not even sure if I
control the licensing.
I think the schemas could be enhanced in a few areas, documentation,
licensing, and ref naming. Suggestions are welcome, in schema form.
While Roy probably named his refs by hand, I’m looking for something
automated. Perhaps we could leverage autonaming using a web tool, but i
doubt if that’s repeatable. I believe the JSON schema community has
addressed documentation, but I am blissfully unaware of such things.
I do know that the specification currently includes iri-reference, so I’ll
probably be looking at whether ajv-formats now includes iri-reference:
“uri:A string instance is valid against this attribute if it is a valid
URI, according to [RFC3986
<https://json-schema.org/draft/2020-12/json-schema-validation#RFC3986>].
uri-reference:A string instance is valid against this attribute if it is a
valid URI Reference (either a URI or a relative-reference), according to [
RFC3986
<https://json-schema.org/draft/2020-12/json-schema-validation#RFC3986>].iri:A
string instance is valid against this attribute if it is a valid IRI,
according to [RFC3987
<https://json-schema.org/draft/2020-12/json-schema-validation#RFC3987>].
iri-reference:A string instance is valid against this attribute if it is a
valid IRI Reference (either an IRI or a relative-reference), according to [
RFC3987
<https://json-schema.org/draft/2020-12/json-schema-validation#RFC3987>].
uuid:A string instance is valid against this attribute if it is a valid
string representation of a UUID, according to [RFC4122
<https://json-schema.org/draft/2020-12/json-schema-validation#RFC4122>].”
John
On Sun, Oct 5, 2025 at 6:14 PM John Carlson <yottzumm at gmail.com> wrote:
> No need for response! I’m realizing I should get the bboxSize for a
> couple of humanoids in order to scale position interpolators.
>
> Since there are multiple drafts of JSON meta-schema (aka JSON schema), i
> have been keeping track of the X3D JSON schema generation code versions. I
> personally would work from 2020-12 backwards if we want to cover all drafts.
>
>
> https://github.com/coderextreme/X3DJSONLD/blob/master/src/main/python/etgenerateJSONschema.py draft
> 7.
>
>
> https://github.com/coderextreme/X3DJSONLD/blob/master/src/main/python/etgenerateJSONschema2019-09.py
>
>
>
> https://github.com/coderextreme/X3DJSONLD/blob/master/src/main/python/etgenerateJSONschema2020-12.py
>
>
> I believe Roy’s schema was draft 7, or I upgraded.
>
> Some of the draft 7 code was carried (updated) in other versions:
>
>
> https://github.com/coderextreme/X3DJSONLD/blob/master/src/main/schema/geoSystem.schema
>
>
> Autogeneration of this part of X3D JSON schema is highly desired, and
> should be sought first.
>
> If X3DUOM v3.0 to v3.3 is also kept up to date, we should be able to
> easily set up JSON schemas for several versions of X3D architecture as
> well. This probably means 20+ schemas to cover all cases. At one point,
> I was covering all recent X3D architecture versions, 3.0 through 4.0.
>
> This is a skeleton script to do that, for JSON draft schema 2020-12.
>
>
> https://github.com/coderextreme/X3DJSONLD/blob/master/src/main/python/generateSchemas.py
>
> I do realize that .xslt is good for XML formats, but I have a warm place
> for ElementTree. It’s not the same as Java XML parsing. Definitely worth
> checking out! Note that I don’t believe that ElementTree requires an
> extra download at all! BeautifulSoup, Pyxie, DOM and SAX appear to be
> available as well. Hmm!
>
> I, too, would enjoy the challenge of improving JSON schema, but I suspect
> you will beat my fiddling! I certainly couldn’t accomplish what you and
> Holger did creating JSON files. I’m only playing with one string!
>
> We should probably discuss componentized and/or profilized schemas. Also
> browser specific schemas (X3DUOM versions for specific browsers). I can’t
> really wrap my mind around the complexity, currently. Extra help is
> certainly welcome, but let’s focus on 1-2 versions first! Note that my
> code used to support v3.* and v4 of X3D, but now covers v4.0.
>
> We should probably have a face-to-face meeting about missing inheritance
> in X3DUOM. There might be something that’s not communicated over email
> well. I can also divert to sourceforge.
>
>
> I will speak with my wife about rejoining the Consortium, as you
> apparently invited me in another message. My daughter is currently in
> college and is planning study abroad. My wife and I are living on fixed
> income. I have a 2016 desktop which could be traded for, but it probably
> doesn’t do Windows 11 or fancy gpus, comes with a Nvidia GTX 980. I have
> run Linux on it. It was designed for a 1080 or 1080 Ti. It runs on a
> Samsung SSD which I ran regression tests on, so I don’t know TTL, an expert
> would know better. I can at least install a version of Linux. I upgraded
> mainly for Windows 11 and to get a raytracing graphics card.
>
>
> John
>
> On Sun, Oct 5, 2025 at 2:52 PM Don Brutzman <don.brutzman at gmail.com>
> wrote:
>
>> Thanks for thinking ahead. I will let you and mailing list know when I'm
>> ready to engage on this topic - not now, first things first.
>>
>> all the best, Don
>> --
>> X3D Graphics, Maritime Robotics, Distributed Simulation
>> Relative Motion Consulting https://RelativeMotion.info
>>
>>
>> On Sun, Oct 5, 2025 at 12:50 PM John Carlson <yottzumm at gmail.com> wrote:
>>
>>>
>>> On Sun, Oct 5, 2025 at 1:19 PM Don Brutzman <don.brutzman at gmail.com>
>>> wrote:
>>>
>>>> [cc: Dick and Joe]
>>>>
>>>> Thanks for helpful information John. Again agreeing. As recently
>>>> repeated publicly several times, indeed for several years now:
>>>>
>>>> - We are developing each specification in order. Getting XML,
>>>> ClassicVRML and Compressed Binary ready and consistent is a big step, so
>>>> that the followin encoding specifications can have similar form and
>>>> corresponding functionality.
>>>>
>>>>
>>> I don’t have a problem with waiting on JSON standards. All that it
>>> really affects is things like incorporation into Castle Engine/Viewer. I
>>> don’t really use X3D JSON for HAnim work, and am currently using Python,
>>> XML and VRML. X3DJSONLD has a critical foundation on JSON, but that should
>>> be able to be easily transitioned off JSON, since it mainly relies on DOM.
>>>
>>>>
>>>> -
>>>> - Next encoding specifications are EXI, JSON, and Turtle (for
>>>> Semantic Web).
>>>> - We will autogenerate an X3D JSON Schema from X3DUOM, no doubt
>>>> starting with patterns you have established.
>>>> - We have a huge existing test suite of JSON models and will be
>>>> able to verify and validate thoroughly.
>>>> - We will align with whatever JSON Schema is most authoritative.
>>>> - I do not know what ISO will say about using a draft JSON schema -
>>>> that is not a standard.
>>>>
>>>>
>>> Point them at the ECMAScript and JSON standards and point out that VRML
>>> doesn’t have a schema. If we can demonstrate effectively that XML Schema
>>> can validate X3D JSON, that might be good enough. JSON schema will be in
>>> the standard, but informative, not authoritative.
>>>
>>>>
>>>> -
>>>> - It is worrisome and very strange that JSON schema is still draft
>>>> after so many years. Why? What is broken or missing?
>>>>
>>>> Just found a possible answer here
>>>> <https://json-schema.org/blog/posts/future-of-json-schema>... will
>>>> push that discussion to the list.
>>>>
>>>> Dick and I are proceeding at best possible speed, building consensus
>>>> standards takes time.
>>>>
>>>> Thanks for your many efforts. Onward we go...
>>>>
>>>> all the best, Don
>>>> --
>>>> X3D Graphics, Maritime Robotics, Distributed Simulation
>>>> Relative Motion Consulting https://RelativeMotion.info
>>>>
>>>>
>>>> On Sun, Oct 5, 2025 at 2:51 AM John Carlson <yottzumm at gmail.com> wrote:
>>>>
>>>>> Don, here is an informative glTF (JSON) schema. I believe their
>>>>> preferred format is glb in the spec. Since X3D JSON can be validated with
>>>>> XML schema, there’s no need to holdback JSON development for
>>>>> standardization.
>>>>>
>>>>>
>>>>> https://registry.khronos.org/glTF/specs/2.0/glTF-2.0.html#appendix-a-json-schema-reference
>>>>>
>>>>> The reason I wanted JSON schema is X3DJSONLD.* was under development,
>>>>> and I needed some way to validate what was coming out of X3dToJson.xslt.
>>>>> Other solutions involved converting JSON to DOM for validation , and were
>>>>> developed once X3DJSONLD more mature. X3DJSONLD in X3DJSAIL, X3DOM, X_ITE
>>>>> and Castle assume DOM validation. I don’t want to add a bunch of bloat for
>>>>> another validator. If people want to add JSON schema validation to those
>>>>> tools, I do have a little expertise. I do feel there might be some
>>>>> pushback about it.
>>>>>
>>>>> While X3D JSON schema can catch certain things like an SFNode being
>>>>> treated like an MFNode, and validation on the web is possible with XML
>>>>> schema, XML schema endures as the golden standard, i haven’t heard that XML
>>>>> schema is being sourced from X3DUOM. It seems like we have 3 standards for
>>>>> similar things. Perhaps people should look at each other’s standards and
>>>>> figure out how to make standards more effective, like detecting MFNode vs
>>>>> SFNode in XML conversion tools, and ordering of nodes in JSON schema.
>>>>>
>>>>> I think that maintaining fewer things will lead to more nimble
>>>>> standardization. I think that ensuring X3D to JSON (and more) stylesheets
>>>>> work on the web and on the server is preferable over adding additional
>>>>> schema. Even doing something with SaxonC and Python would help Python JSON
>>>>> output (beyond what Aaron is achieving), and add to better synchronization
>>>>> between X3DPSAIL and X3DJSAIL.
>>>>>
>>>>> If need be, I can hand over my schema creation scripts for converting
>>>>> to stylesheets.
>>>>>
>>>>> Again, last I heard about JSON schema standardization, they want to
>>>>> self-publish.
>>>>>
>>>>> Since all tools I am aware of convert JSON to DOM, XML validation is
>>>>> preferable. Otherwise, we should look at X3D JSON standardization through
>>>>> API validation, since we have to do that anyway.
>>>>>
>>>>> I realize the web3d consortium has their own reasons for developing
>>>>> their own schema (standards organizations develop test suites), I think
>>>>> effort is better spent on APIs which consume and produce JSON. Blender
>>>>> seems like something obvious.
>>>>>
>>>>> Perhaps instead of developing solely a family of standards, Web3d
>>>>> could develop a family of standards and then recommendations about the
>>>>> standards, so standardization isn’t delayed for decade or more.
>>>>> Recommendations could be like VRML to X3D DOM conversion.
>>>>>
>>>>>
>>>>>
>>>>> John
>>>>>
>>>>> On Sun, Oct 5, 2025 at 12:09 AM Don Brutzman <don.brutzman at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> thanks John. next three standards will be EXI, JSON, and Turtle.
>>>>>
>>>>> hopefully JSON someday has an official schema specification to
>>>>> finally... they are still stuck on 2022 draft IETF RFCs, not sure why.
>>>>>
>>>>> - https://json-schema.org/specification
>>>>>
>>>>> all the best, Don
>>>>>> --
>>>>>> X3D Graphics, Maritime Robotics, Distributed Simulation
>>>>>> Relative Motion Consulting https://RelativeMotion.info
>>>>>>
>>>>>>
>>>>>> On Sat, Oct 4, 2025 at 1:53 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
>>>>>>>
>>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20251006/3350f1ba/attachment-0001.html>
More information about the x3d-public
mailing list