The old gl.spec & related files are being retired, replaced by an XML-based description of the GL, GLX, WGL, GL ES, and EGL APIs as has been promised since slightly before the Dark Ages. The XML files & Python scripts to process them and generate headers are in the public-access portion of Khronos Subversion, and the GL, GLX, and WGL headers generated from them are also there and linked from the registry index.

The GL, GLX, and WGL headers should be equivalent to the old headers generated from .spec, although they are structured differently and in some cases, enums and entry points have moved from one extension #if block to another (each extension / core version now references all the tokens and commands it introduces, even if some prior extension also references them, and if a token or entry point appears in more than one extension, it will only appear in the .h at the first place it's referred to). The GLES and EGL headers on the Khronos Registry website will probably be updated to be generated from the corresponding Registries fairly soon, if the corresponding Working Groups are OK with that.

The new format includes a Relax NG compact schema, and all the XML validates against that. There's a short description of the tags in the README.txt. It captures most, but not all of the information in the .spec files in a more semantically expressive way, describes types in C syntax instead of the generic type syntax used in .spec, and does not include array length information (which was often inaccurate in the .spec files). If you are using .spec to generate bindings to other languages, you'll have to translate the C types to your output types. The header generation scripts are intended to be extensible to other output formats fairly easily, though we haven't done anything with it but C headers.

The old .spec files and GL, GLX, and WGL headers generated from them are still available under a relocated Subversion path, but we don't plan to update .spec in the future. A large number of .spec bugs that people had submitted have been addressed in the XML registry and closed, or in a few cases, WONTFIXed because they referred to specific properties of .spec that don't exist in the XML. It might be possible to do a mechanical translation from the XML back to .spec format - it would not be easy, because the XML is structured very differently and there are a lot of one-off hacks in .spec that aren't needed in the XML - but hopefully people can adapt their uses to work directly with the XML instead. It's possible the schema will need additions to accomodate some uses, feedback on that can be provided here.