The base of the parser is an auto generated, validating, COLLADA specific, xml parser, that alternatively uses libxml2 (fast) or Expat (little bit slower), both of them are MIT licensed. The C++ code for this parser is generated from the COLLADA XSD by a Java program. This parser has callback functions for each COLLADA element (SAX style parsing). One for the beginning of each element, one for the end of each element and, if character data is allowed inside this element, also one for that data. The begin functions parse the attributes, if any, convert them to the corresponding c++ data type according to the XSD and provide them in a struct. The names of the members in this struct correspond to the attribute names in COLLADA. Similarly, the parser parses the character data, if any, inside elements, converts it to the corresponding c++ data type according to the XSD and calls the data function with these values stored in an array. Since sax based xml parser do not necessarily pass all character data at once, that data function might be called multiple times for one element and provide the data in pieces (e.g. large float arrays are passed during several calls).
The end function is called when the element is closed and has no parameters.
On top of this auto generated parser we have implemented two more components. A data model (currently called COLLADAFramework) and a COLLADA parser (loader) which fills that model (currently called COLLADASaxFrameworkLoader).
The data model consists of atomic objects (Geometry, Scenegraph, LibraryNodes … ) which are passed to any software that wants load a dae file using this loader. To receive the objects, this software needs to implement the COLLADAFW::IWriter interface. The loader then calls the methods of this interface, as soon as an atomic object has been loaded completely, e.g. the writeGeometry method is called as soon as the end_geometry function of the generated
sax parser has been called. Therefore, the atomic objects are passed in the order they appear in the dae file, which requires that implementers must be able to handle them in arbitrary order. If this is not possible, one can parse the dae file more than once. For instance the COLLADAMaya plug-in uses this technique, since it needs to know the scene graph, before it can handle geometries. The methods of the interface pass pointers to the objects that are only
valid inside the call of this method. As soon as this method returns, the object might be deleted and the pointer becomes invalid. This approach reduces the memory consumption, since it needs to hold only one atomic object in memory a at time. Each atomic object has a unique id used to match objects and references to them. The COLLADASaxFrameworkLoader already resolves urls in COLLADA and uses them to assign these unique ids.
There is a very simple sample implementation for the Sax Parser available that converts DAE files into binary Ogre3D meshes that might server as a starting point for any game development.
These libraries are all extremely fast (500MB DAE file parsing takes ~2 sec) and have no memory overhead. The SAX based approach is a bit more difficult to handle but the framework allows you to create an importer more reliable and faster than with the COLLADA DOM libraries. Not as simple as FBX yet but available under the MIT license.