Promotion of COLLADA Extensions

Promotion of a COLLADA extension refers to moving it from single-vendor to multi-vendor or Khronos-approved status, usually by changing the profile attribute of the extension name string. This is sometimes done when an extension is successful and more Implementors want to support it. This document describes the steps to follow when promoting an extension.

Is promotion required?

Changing the names creates a significant burden for ISVs supporting the existing extension. It should not be done gratuitously; if the existing schema is sufficient, there's no inherent reason that an implementation shipped by one vendor cannot advertise and support an extension using another vendor's prefix. Note: This would happen when a single vendor profile extension changes name to multi-vendor, or the work group standardized an extension and possibly redesigned it.

If you do this, make certain that the original vendor agrees to freeze the definition of the extension, and that what you ship is identical in behavior to what the original vendor is shipping. Shipping what appears to be the "same" extension while implementing different behavior on multiple platforms is a great disservice to ISVs trying to use extensions, and to COLLADA in general.

Do not, under any circumstances, ship an extension defined by another vendor without first clearing it with that vendor.

Note: An extension would only move into the COLLADA specification if the work group standardizes it in a newer specification release.

Promoting without changes in semantics

If you nevertheless want to promote an extension from vendor-specific to e.g. EXT status, without changing the schema definition or spec'ed semantics of that extension, then advertise and export both the old and the new forms of the extension for maximum backwards compatibility. This means that:

• Both extensions' strings should be included in the wiki registry.

Promoting with changes in semantics

If you are promoting an extension while changing its schema definition or spec'ed semantics of that extension, do not treat it as identical to the old extension. This means that:

• Any new extensions that differ in definition from the original extensions should be assigned new profile string values, and those values published in the wiki registry.

None of this should be taken to indicate that code cannot be shared between implementations of the old and new extensions; simply that the implementation must be able to distinguish whether the old or new form is being called, since they are de facto different extensions despite sharing similar purposes.

Khronos Extension Approval Process

A Khronos approved extension must be proposed and developed (contributed) by either a Khronos member or an external company or person who has signed the Khronos Reviewers Agreement. In the case of a Multi-Vendor Extension, all contributors must be Khronos members or KRA signatories.

IP encumbered technology will not be accepted.

The COLLADA work group creates the proposed final draft of the extension. When the extension is to be publicly distributed – then it must go through ratification to get IP protection (See Khronos membership agreement). When the draft is ready for ratification, it is tabled for review by the Khronos Board of Promoters and general membership. Thus begins the 45 day ratification period.

Extension Approval Requirements

Single-Vendor Extension must:

• Be well documented on the collada.org wiki, following the How To Create Extensions Process.
• Have one complete vendor implementation.
• Have sample data posted to collada.org according to process.
• Be contributed by a Khronos member or KRA signatory (see above).

Multi-Vendor Extension must:

• Meet Single Vendor requirements.
• Have two complete vendor implementations.
• Be contributed by a combination of Khronos members and/or KRA signatories (see above).

Khronos Extension must:

• Meet Single Vendor requirements.
• Be Approved by COLLADA work group.