[x3d-public] X3D Specifications ready for review: XML, ClassicVRML, and Compressed Binary Encodings

Don Brutzman don.brutzman at gmail.com
Mon Oct 6 10:16:38 PDT 2025 

Glad you are a member!

Searching for "web3d license" instantly reveals

   - Web3D Consortium: License
   - https://www.web3d.org/license

More information about license can be found at

   - X3D Scene Authoring Hints: License
   -
   https://www.web3d.org/x3d/content/examples/X3dSceneAuthoringHints.html#license

Have fun with X3D! 😀

all the best, Don
-- 
X3D Graphics, Maritime Robotics, Distributed Simulation
Relative Motion Consulting  https://RelativeMotion.info


On Mon, Oct 6, 2025 at 8:25 AM John Carlson <yottzumm at gmail.com> wrote:

> 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/fbbeeb93/attachment-0001.html>

More information about the x3d-public mailing list