[Public WebGL] Standard issues

Florian Bösch [email protected]
Thu Mar 19 00:56:24 PDT 2015

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).

*TL;DR* 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:

   1. Read the ES specification
   2. Read the WebGL specification and note that this part is omitted (a
   diff delete)
   3. Read the core reintroduction extension (a diff add)
   4. 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20150319/2689dc3a/attachment.html>

More information about the public_webgl mailing list