Update normative language

[lexaknyazev]

General updates

• Use BCP 14 normative language.
• Properly list all external references.
• Expand the Samplers section.
• Expand material texture descriptions.
• Reduce emphasis on OpenGL.
• Minor language edits.

Specific updates

• Restrict certain PNG and JPEG variations.
• Full rewrite of JSON encoding section, relaxing some of previously-unenforced restrictions.
• Explicitly allow IRIs.
• Explicitly disallow bufferView.byteStride for buffer views that do not contain vertex attributes.
• Elaborate on image media types handling.
• Restore accidentally removed vertex color usage.
• Discourage use of zero-length GLB BIN chunks.

[javagl]

I started a review of the changes, but it's pretty large. I locally took some notes (a bit of nitpicking, and some things that I wondered about, but where, at some point, I have to assume that they have been sorted out in certain issues, and the changes here are just the result of a larger discussion). Two things for the process:

• Is there any timeline for the review?

• Do you prefer inlined comments in the review, or a list with entries like

  • https://github.com/KhronosGroup/glTF/pull/1997/files#diff-ca628c11679a8c4c0c4031440c7c1cda27c8896ebc87c3bd1e8640efc8942d99R147 Broken formatting of "[[utf8]" (missing "]", I guess)

  (The first may be more convenient (and avoid duplication), but the second one may be more handy and less scattered, by having all comments by reviewers in one place. I'm locally keeping the notes in such a list, but would transfer them into inline comments eventually, if you prefer that)

[lexaknyazev]

Since inline comments naturally support threading, I'd prefer to use them since the diff is indeed large (although most of it is trivial). Feel free to ask about any confusing changes.

[oddhack]

I started running through this and soon noticed a lot of omission of definite & indefinite articles (such as "the keyword", "a buffer", "an object") where they're grammatically appropriate. On the grand scale of things this is more jarring to read than a spec bug, and I didn't try to enumerate them past the first few examples. But it is still worth addressing.

[lexaknyazev]

I started running through this and soon noticed a lot of omission of definite & indefinite articles (such as "the keyword", "a buffer", "an object") where they're grammatically appropriate.

You're right. This is a long-standing issue since the very first glTF drafts.

[javagl]

The missing articles are something that I also noticed, but saw it in the same way as oddhack: It's usually not relevant for the correctness or preciseness of the spec itself.

But to be concrete: Should/could this be addressed in this review? These could be many small comments, and it may cause some noise that distracts from possibly more important aspects that are actually supposed to be reviewed here.

Another option would be to really focus on the normative/spec aspect here, and do a dedicated pass with editorial changes later. The corresponding PR could probably be reviewed quickly and easily, because it would just insert some "a"s and "the"s here and there, without any other changes.

(This is somehow related to the question about the timeline. I think it was mentioned in the calls (or maybe the mail thread?), but: When is the the deadline for this update?)

[neiltrevett]

When is the the deadline for this update?

We have two deadlines:

1. Any IP-impacting changes must be implemented and agreed by the meeting next week (July 7th) so we can vote to submit the specification for ratification. No IP-impacting changes would then be permitted without restarting the ratification review
2. Any non-IP-impacting changes (e.g. formatting, clarifications, informative additions, adding missing articles that don't change meaning) can be made at any time during the 6-week ratification review and beyond, up to when we formally release the specification, or submit it to JTC 1, which ever is the sooner - latest early September.

Neil

[donmccurdy]

Reviewed as far as the beginning of the Geometry section – will try to review further soon!

[donmccurdy]

In rendered form it's difficult to find something quickly among these references, because the keywords are somewhere in the middle of the line. Would it be appropriate to put the title first, rather than the source, or prefix with a keyword like "JSON"?

[donmccurdy]

I understand why the use of a .gltf extension for JSON glTF files is not required — we don't want to prohibit use cases like REST APIs, or perhaps like .vrm.

But, is it worth including some language that normatively prohibits a JSON glTF file using a .glb prefix, or a binary GLB file using .gltf? Such mixups would be unfortunate.

[donmccurdy]

Would it be valid for an extension to define a new "kind" of data that supports interleaving? Trying to accommodate EXT_mesh_gpu_instancing instance attributes and perhaps future extensions here.

[javagl]

I went through the remaining document. (Sorry, some comments are "nitpicking" about formatting, but I hope that they are not too distracting).

One (inlined) point that might relevant for the "normativeness" is: In how far can the Filtering behavior be prescribed (e.g. the necessity to be able to generate MipMaps)?

Other, general points:

• Sometimes, the wording is "instanced", and sometimes "instantiated". Do we make a difference here?
• The connection between the component types (and the "normalized" flag) and the corresponding values (like 5126 for float) is not really clear, now that the references to the constants like GL_FLOAT have been omitted...

---

This may just be a lack of understanding on my side:

• I never deeply dug through the maths of PBR, but... when talking about "metal" and "non-metal" here with the "metal" value being in [0,1], then I wonder: Is 0.0001 already "metal", or is 0.9999 still a "non-metal"? (Maybe this becomes clear in the appendix, but I didn't know what to do with this information, at this point, from a specification perspective...)
• It's nice that the sRGB computations are illustrated with an example here, but ... someone who's reading that will most likely have NO idea where these numbers came from. There's a link to some IEC spec, for ~175 bucks, so that may be safe from a "normative-ness" standpoint. But someone who tries to understand and implement that may have to do some websearches (and eventually stumble over http://davengrace.com/cgi-bin/cspace.pl ...)

---

Formatting/linking issues:

• "PropertiesReference.adoc" and "JsonSchemaReference.adoc" are not linked yet, but I assume that they will be in the future
• https://github.com/KhronosGroup/glTF/pull/1997/files#diff-ca628c11679a8c4c0c4031440c7c1cda27c8896ebc87c3bd1e8640efc8942d99R1976 The matrices are not properly formatted
• Formulas at https://github.com/KhronosGroup/glTF/blob/15f3ea26d5e539a67afe9dcfe29410d736097002/specification/2.0/Specification.adoc#b32-specular-brdf are not properly formatted

[javagl]

To summarize: I did not find any obvious issues. Some details are discussed in the inlined and PR comments.

[javagl]

I did another quick pass, focussing on the changes, and think that they indeed add clarity. I cannot say much about the fallback behavior for the MipMapping on a technical level, but reducing the requirement from MUST to SHOULD IMHO makes sense, because it's usually beyond the control of the client.

No further comments for now, except for a detail regarding the ROWS * SIZE_OF_COMPONENT part (inlined).

[lexaknyazev]

Let's continue the refinements in #1901.