KhronosGroup / KhronosGroup/glTF

About using allOf for single types

Open
#2,062 4 comments 0 reactions 1 assignee Claimed by @lexaknyazev View on GitHub
Dominant language
HTML
Stars
7.8k
Forks
1.2k
Avg merge
17h 26m
Merged PRs (30d)
5

Description

The schema currently uses `allOf` consistently to refer to single types. For example, in [`accessor.bufferView`](https://github.com/KhronosGroup/glTF/blob/1a3c2e3c436921cdd93f8ea484d209ba6b20115d/specification/2.0/schema/accessor.schema.json#L10) :

"bufferView": {
"allOf": [ { "$ref": "glTFid.schema.json" } ],
"description": "The index of the bufferView.",
"gltf_detailedDescription": "The index of the buffer view. When undefined, the accessor **MUST** be initialized with zeros; `sparse` property or extensions **MAY** override zeros with actual values."
},

From what I read in the documentation about [`allOf`](https://json-schema.org/understanding-json-schema/reference/combining.html#allof) and [`$ref`](https://json-schema.org/understanding-json-schema/structuring.html#ref), to my current understanding, it should be possible to replace this use of `allOf` with a plain `$ref`, as in

"bufferView": {
"$ref": "glTFid.schema.json",
"description": "The index of the bufferView.",
"gltf_detailedDescription": "The index of the buffer view. When undefined, the accessor **MUST** be initialized with zeros; `sparse` property or extensions **MAY** override zeros with actual values."
},

The difficulties of modeling inheritance in general (c.f. https://github.com/KhronosGroup/glTF/issues/1144 ), the notes about "Subschema Independence" in the documentation, and (as usual:) possible changes between the Schema drafts that I may not yet have fully understood make me hesitate a bit here.

But I wondered whether there would be any semantical difference between the two options, and whether the plain `$ref` should be preferred for cases where `allOf` otherwise contains only a single type.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.