We're often getting into sticky situations in debates about core specifications and extensions. And a couple things I'd like to remark on that are problematic. To make my point, I'll need to establish we all understand what this standard is, and how it's defined (because I sometimes get the impression that's not the case).
WebGL is a diff of ES core. Extensions are a diff of ES core. WebGL extensions are a diff of ES core in harmony with the diff of WebGL to ES. Extensions carry one bit of information (presence or absence).
WebGL is an implementation of OpenGL ES. WebGL does not produce its own complete specification. The WebGL specification is mostly a document describing the IDL of the interface, additional bits tacked on and bits omitted. As such WebGL is basically defined as a diff to ES.
The actual specification of WebGL is ES.
Extensions to OpenGL ES are diffs to the ES specification. This is so for various legacy, technical and political reasons. But for whatever reason, that's how it is.
In the same vein, a WebGL extension is a diff on the WebGL specification, which is a diff on the ES specification...
An additional remark about extensions, for the most part, extensions communicate one bit of information (presence or absence). They also define additional functions/constants to be made available if present, that will only work if that extension is present (conveniently they provide them on the extension namespace).
And here is where it gets sticky.
-- Non ES underlying extensions --
TL;DR If you think you need an extension and it is not based on an underlying ES extension, you are probably wrong.
The reasons you're wrong may include any of the following:
- You want to communicate N bits to the user, but your extension itself only carries one bit, and it doesn't contain any interface to provide additional bits.
- You want to have some sort of standard that can evolve, but if you make it an extension, it's frozen, forever. You can never, ever change it.
- You want to provide a temporary fix to a gap in functionality and propose the extension for that reason, but you don't consider that your extension will now live forever in the registry, and will have to be supported by every vendor, forever (or at least as long as they support WebGL N, which is a long time indeed).
- You want to provide additional behavior, but your extension does not change the behavior (i.e. is not a diff) to the ES spec
It needs to be noted that extensions are not revisioned either, so you cannot resolve a "living standard" issue with that, because it doesn't exist for extensions.
Additionally to the other logical points, there are practical reasons why non ES underlying extensions have a hard time. If an extension has been entered into the ES registry all the debate about its definition, merits, drawbacks, caveats etc. have essentially been resolved. If it gets proposed to WebGL, there are very few issues to resolve left, this substantially shortens the amount of debate required. If you propose an entirely new extension, you might be under the mistaken impression that this process is going to go as smoothly as proposing an ES underlying extension, but this is often not the case. It's not the case because none of the aforementioned debate that ES extensions have already stood up to, has happened, and it needs to happen. So it's unfortunate, but that's how it is.
-- Omitting core functionality --
TL;DR I don't think we should do this if at all possible.
If we omit core functionality of an ES specification (for whatever reason) we create a problem for several reasons:
- Future revisions of the ES specification will build on those core features assumed to be present. So a small diff edit (a deletion) in a current specification, will result in an automatic larger diff edit in future revisions (unless the issue is reconciled).
- Some ES Extensions (which are often the precursor to future ES revisions) that are diff edits (additions mostly) that build on those core features will also be impossible to make, because the underlying core specification has been diff edit deleted.
- Even if substantial will exists at the time to introduce the extension, it means that the core functionality needs to be re-introduced first as a diff edit addition. Additionally that extension instead of being an edit to the core (as it is on the underlying ES registry), is now an interaction with another core feature reintroducing extension.
So as a worst case, the living WebGL specifications behavior becomes cumbersome and awkward.
In order to derive a complete specification for such a feature you'd need to follow these steps:
- Read the ES specification
- Read the WebGL specification and note that this part is omitted (a diff delete)
- Read the core reintroduction extension (a diff add)
- Read the extension specification depending on the core reintroduction extension (an extension diff edit add)
And it gets even funnier if the underlying ES extension also interacts with other ES extensions itself.
In my opinion, we should try to avoid that kind of thing as much as possible, it makes life for everybody (vendors and users) very hard.
-- Non public discussion/resolutions --
TL;DR Please make it public.
The WebGL standard belongs to Khronos and is maintained by the WebGL WG. The WebGL WG is not a public club, it's private with membership fees and an admission process.
But as is often the tradition for web related standards, a lot of discussion on specifications/extensions happens for WebGL in the public space (primarily here on the public WebGL ML). This is also the case for much of the work that WhatWG and W3C do (though their charters and methods do somewhat differ).
A key part in making this process successful is to inform the public space about decisions taken in a private club, such as:
- ahead of meeting topics
- during meeting notes
- taken resolutions
- summaries and reasoning
It's effective because in that way, a ensuing public discussion will not have to rehash things that've already been effectively discussed in a private club, and a public discussion can also be focused on topics that participants feel have not been sufficiently covered by the private club.
This is not happening for WebGL right now. It is often the case that specification edits appear in the public space "out of thin air". At best there'll be a short note on the github commit comment.
I'd ask you to make this process more transparent for the sake of efficiency and public inclusion.