Usage of null in glTF

[lexaknyazev]

null is one of four JSON primitive types. At the current state of spec, no field can have null as a value.
Yet, there could be reasonable use cases for it:

• Stub for required uri fields instead of an empty data URI (because such URI means actually "empty plain text string" and requires syntax check in general case):

  "buffers": {
    "binary_glTF": {
      "byteLength": 12345,
      "uri": null // instead of "data:,"
    }
  }

• A way to mark a mesh as non-renderable by setting [mesh.primitive.]material : null.

Allowing field to be "nullable" will require a small change in JSON schema, e.g.:

{
    "$schema" : "http://json-schema.org/draft-03/schema",
    "title" : "buffer",
    "type" : "object",
    "description" : "A buffer points to binary geometry, animation, or skins.",
    "extends" : { "$ref" : "glTFChildOfRootProperty.schema.json" },
    "properties" : {
        "uri" : {
            "type" : ["string", "null"] // <------
            "description" : "The uri of the buffer.",
            "format" : "uri",
            "required" : true,
            "gltf_detailedDescription" : "The uri of the buffer.  Relative paths are relative to the .gltf file.  Instead of referencing an external file, the uri can also be a data-uri.",
            "gltf_uriType" : "application"
        },

[javagl]

One should be careful here. The treatment of null may be a bit subtle. Assigning a "special" meaning to a "special" value may always be a source of confusion (and some purists demonize the use of null in general).

For example, in the non-JavaScript world, it may be hard to distinguish between a property that has the value null, and a property that simply was missing (because it was optional). I think JavaScript has another level of nothingness, namely undefined, so it may not be an issue there, but may be worth pointing out nevertheless.

Would the use of null be limited to properties that are marked as required? One could argue that this boils down to making a required field optional through the back door (but I'm not sure whether this is true on a strict, technical level).

The case of the uri for buffer, image and shader is particularly fuzzy. The binary glTF spec says

a runtime can ignore the uri property

which is a remedy to the uri being marked as required in the main spec - but I can imagine that some parsers would bail out if it was not a valid URI at all.

For the poroposed case of "switching off" a mesh primitive by setting its material to null, one could consider whether it wouldn't make more sense to simply remove the respective mesh primitive from its owning mesh. Alternatively, one could say that something like this could or should be modeled more explicitly and cleanly by introducing some boolean isRendered property....

---

(Note that these are not strict arguments against this proposal. There are just some caveats to consider)

[lexaknyazev]

Thanks for feedback, @javagl!

There are some caveats in JavaScript, too:

var a = {};
a.b = null;
a.c; // undefined
a.c == a.b; // true
a.c === a.b // false

Maybe, we can resolve those two cases with other means and avoid null completely.

My main concern with uri case is that extensions can't make required fields irrelevant:

Extensions can introduce new properties (including properties that reference external data, and the extension can define the format of those data), new parameter semantics, reserved ids, and new container formats.

And "data:," has a very concrete meaning: omitted MIME type implies text/plain, while binary data must be application/octet-stream. null feels much more strict here for me.

Material case was just another example of possible null usage (think of invisible walls or simplified geometry for physics located near to renderable mesh and automatically sharing all node transforms). Again, it's just a use case to think of, nothing more.

[javagl]

This may be a too specific point for the question about the usage of null in general, but I also stumbled over the fact that extensions can not make properties irrelevant. In that sense, an extension like binary glTF is not "backward compatible", and a loader cannot gracefully handle it.

(If null was allowed for uri in a new version of glTF, this would be a different story).

(BTW: For the particular case of the URI in binary glTF, I considered to weasel out of this question not by assigning data; to the URI, but instead assigning "the URI that the entity should have if it was not a binary glTF" - something like an auto-generated file name. This is still brittle, I know...)

[lexaknyazev]

an extension like binary glTF is not "backward compatible", and a loader cannot gracefully handle it.

Looks like it doesn't mean to be "backward compatible" at all. Assets have another file extension (.glb) and moreover if a runtime sees unsupported extension in the extensionsUsed list, I think, it should abandon such file anyway.

"the URI that the entity should have if it was not a binary glTF" - something like an auto-generated file name.

Or just an empty string or an empty fragment (#). Still feels like magic value.

[pjcozzi]

Great discussion here, thanks @lexaknyazev @javagl!

It sounds like introducing null throughout may come with some caveats and we could be rushing it for 1.0.1 in ~2 weeks.

It sounds like the main concern is that extensions can't remove properties, which as also be troublesome to me; I wrote the Binary glTF extension and clearly didn't handle the uri property perfectly.

Perhaps we should refocus this discussion on extensions and continue post 1.0.1?

[lexaknyazev]

Surely post 1.0.1.

[pjcozzi]

@lexaknyazev in practice, do you still think this is worth considering?

[lexaknyazev]

We still don't allow null schema-wise. Future revisions or extensions could have it though.

[lexaknyazev]

Schemas and the validator do not allow explicit null values. Closing as there's no further action here.