Using JSON-SCHEMA for format definition is not in the interest of the GLTF format

[nbouayad]

Dear community,
I would like to draw your attention that the JSON-SCHEMA format is not mature and is not well supported, therefore,It makes GLTF binding difficult.
For example, there is no Java library able to generate code directly from the GLTF schemas (jsonschema2pojo does not supports allOf, anyOf...). Java is not the least supported programming language in the world I think....
Concept of multiple inheritances may work with C++ but not for other languages (Apart if you implement a complex logic, and In the case of GLTF, there is no complex logic,just complex definition format).
I would suggest to move to a more mature definition format, or, make sure that It is easy to generate bindings from the definitions.
I am getting frustrated of writing code manually because It is impossible to automate the generation of It.
New extensions may come any time, and It is not understandable that the code generation is not possible to automate (21st Century you know).
Hope that you understand my point.
Best regards,

[javagl]

The JSON-Schema indeed went through some iterations with breaking changes, but I think it is approaching a state that should soon be mature enough to be reliable. And I think that the JSON-Schema is the de facto standard for JSON Schema definitions. Any proprietary/special way of specifying the schema would cut off glTF from the ecosystem that is currently actively being developed around the JSON-Schema.

Or to put it that way: What would be the alternative? How should the JSON structure be defined, if not in a schema that is about to be "standardized" and about to be processed automatically (even if it is currently still under development) ?

---

In the meantime, just a short pointer to https://github.com/javagl/JsonModelGen : As the README says, it is not really intended for public use, is not implemented "nicely", does not offer a configurability that is even remotely similar to that of jsonschema2pojo, but I have used it to generate the *-impl-classes of https://github.com/javagl/JglTF .

This is NOT a recommendation of either library - this is only a pointer. There are some tweaks that are tailored specifically at glTF, but I'll try to keep it up to date, for example, when the glTF schema is updated to use JSON Schema V6.

---

In general, the goal of automating the generation of classes from the schema has also been addressed for other languages and libraries - particularly, for C++. There are many degrees of freedom for how to tackle this, and probably, only time will tell which one turns out to be the most robust and reliable one.

[pjcozzi]

Perhaps close as duplicate with #929?

[innerground]

@javagl , @pjcozzi ,JSON schema is perfect for JSON definition, but is immature and barely supported.GLTF does not requires all the features of JSON Schema.At least,having the guarantee that GLTF is not using multiple inheritance, nor AllOf, AnyOf...would make binding easier and well controlled.A limited subset of JSON schema (Made for programming languages binding) would be perfect.
As example, STEP (AP203, AP214 meant for 3D) are defined using the EXPRESS data modeling language,not saying that It is perfect, at the contrary, but binding is very easy.
I will discuss that with the JSON schema guys.

[innerground]

I come back to my statement about "GLTF does not requires all the features of JSON Schema".After reviewing the schemas, I am even more convinced about that, why using AllOf...If a ref is just enough.We should really help the programmers and not just adopt the JSON schema like this format is for theory and validation only (ie. check XML via XSD for binding, that works for many languages)

[zellski]

I think I don't fully understand the arguments being raised here. What exactly is the problem? I sketched out my own code generator and it doesn't seem insurmountably complex. Furthermore, I've spent the last several weeks working on glTF validation, and believe me, I appreciated the allOf type annotations a great deal even when I was just reading them with human eyes. In any case, whether it's a human or a program reading the data, how can it be better for a formal spec to provide less structural information?

[donmccurdy]

We should really help the programmers and not just adopt the JSON schema like this format is for theory and validation only (ie. check XML via XSD for binding, that works for many languages)

@innerground Do you have other suggestions? Switching glTF to an XML-based schema is not ideal.

[javagl]

Although I'm also curious about suggestions for improvements (which likely to not refer to letting https://github.com/ethlo/jsons2xsd run over the current schema), I have to agree to the allOf point to some extent:

If someone added multiple schemas into an allOf, this would imply multiple inheritance (of state, which is a "Bad Thing®").

Fortunately, right now, there are no uses of allOf with multiple schemas in the glTF spec.

I'll have to re-read the exact semantics of the allOf/oneOf declarations. But from the tip of my head, I don't see why these usages of allOf should not be simply converted to oneOf. This would make clear that only single inheritance is used there.

@lexaknyazev and the other JSON schema experts: Any thoughts about that?

[emackey]

There's some old discussion of oneOf/anyOf in #891.

[innerground]

@zellski,I have to bind Gltf to various languages,such as C/C++,Java...I can do It manually but It is a pain.
By the nature of JSON schema,It can be complicated to anticipate all the possible cases.Also, the format keeps evolving making even more complicated the support of It.

[innerground]

@donmccurdy, JSON schema is fine as long as we guarantee that we only use ref for example,instead of all of,anyoff...

[javagl]

Just a minor detail: anyOf is used with multiple values, in order to model enum types and some of the types in the technique (as it appears in glTF 1.0 and extensions), where the type of a value is simply not known. (This basically corresponds to an Object in Java, or roughly a void* in C++).

Apart from that, I also think that allOf should only be used with a single reference. (Whether it could make sense to emphasize this by replacing it with oneOf has to be investigated).

@innerground Are you using one of the (many, many) JSON-Schema-to-Code generators that already exist, or are you creating your own?

[innerground]

@javagl, I tried every JSON schema code generator,but none supports AllOf,AnyOf...Then I started writing my own but gave up as I encountered many cases which are tricky to manage.Writing the code by hand is painful,but still takes much less time than writing a full code generator.

[pjcozzi]

We are cleaning up the glTF GitHub repo a bit. Closing this due to inactivity. If there is additional discussion here, please use the forum since this is more of an implementation issue than a spec issue: https://community.khronos.org/c/gltf-general