In order to speed-up the loading/saving of complex collada geometries, shouldn’t the specification offer alternative binary formats for <source> elements ?
If the specification enforces the exact binary format, then compatibility would be guaranteed between DCC tools, because each DCC tool would know how to extract the binary data.
Most of Collada specification could remain ascii. Only <source> elements could reference external binary files.
The COLLADA DOM implementation of “.raw” stems from the capabilities of the <accessor> element, as documented in the specification, and the nature of opaque URI resources. I.e. its the <accessor> that describes the (in this case external) resource that is referenced by a standard URI.
So that in that sense it is standard COLLADA although I do not have marketing data about other tools that support it.
A good understanding about URI processing is key. As with any format that is external to COLLADA, and there are many thanks to the numerous image formats, it is up to the URI processor to dereference (i.e. retrieve) the resource. As long as the I/O software has a media type handler to retrieve the data then the <accessor> information provides the mapping from that external storage to the <source> and <input> elements.