Version 1.4 and 1.5 support with DOM

Hello Colladians,

I would like to build an application that can load both Collada version 1.4 and 1.5. The DOM uses version specific libraries that check against the corresponding schema. This way an application is tied to using a specific version of the DOM, but I would like to be able to open a Collada document and decide at runtime which version to use.
How can the DOM to help me with this?

warmest regards,

Roland Smeenk

If you plan to dynamic link to a library at run-time (i.e. dlopen), then you need to make sure each version of the DOM dll has a different pathname or filename.

You app would need to deal with the differences between DOM 1.4 and 1.5 external symbols. One way to handle this is with two stub DLL of functions and variables that don’t exist in the respective DLL versions. E.g. you would dlopen dom14 and stub15 as a pair (or dom15 and stub14).

You would also need to totally insulate your app from any binary incompatibility between the two libs (i.e. function signatures and data structures).

Hi Mark,

that was not really the answer I was hoping for.
You are saying that it is my apps reponsibility to determine if I need the 1.4 or 1.5 version, but all I know when loading a file is that it has a .dae extension and therefore needs to be loaded by the Collada loader plugin. My application will have to inspect the .dae to check which schema it uses before deciding on which version of the DOM to use. I was hoping the DOM would help me with this and offer me a seamless transition to newer versions of Collada in the future. I guess I will stay with Collada 1.4 for a while before transitioning to Collada 1.5.

Thanks,

Roland

Hi Roland,

That is a great feature request to make at the DOM project on sourceforge. The schema specific code is generated by a script. It could generate code within a C++ namespace. Then the build system could offer make options for static/dynamic libraries. Then a higher level utility module could offer options on static/dynamic linking of the schema .dll. This approach would lead to dynamic loading of schema defined extensions too.