Hi,
I'm working on figuring out the best way to implement a partially complete Collada (a format used for representing 3D model data, primarily used in games, see www.khronos.org/collada) importer. I'm thinking of doing this in two steps: 1. Reading the XML data into memory 2. Traversing the document tree, instantiating correct 3D entities based on what I find, and adding them to a scenegraph There are some requirements on the implementation: 1. It shouldn't be complete - Collada is really complex and we won't need all the features, so a complete implementation would be a waste of time. 2. It needs to be really good at reporting errors - due to the complexity of the format, and the fact that we don't want to be restricted by a poor importer implementation, we are likely not to be able to define up front exactly which features of Collada we want to support. So when the importer encounters something it cannot understand, I want it to be able to say that 'I cannot handle feature X, which is used on line Y, column Z in the input file'. 3. It needs to be really easy to add support for new features of Collada. Basically, the strategy is that when our great error reporting tells us that an artist tries to use a feature the importer cannot handle, it should be easy for us to add support for the feature without breaking the overall architecture. 4. It needs to handle XPointers. A common way to reduce the amount of data in a Collada file is to define a library of some kind of graphical entity type, and then refer to that entity using an id (there are multiple ways this is done, unfortunately) when an instance should be created. I've been looking at using some mapping tool like Castor or JiBX to get the data into memory. Castor doesn't seem really suitable (unable to figure out a way to get line numbers), whereas JiBX has pretty nifty support for getting information about the original source. However, JiBX doesn't make it easy to resolve references to other Collada elements, since the most normal way to use JiBX is to destroy the original document structure and create a more easily-used one in Java. Doing so also helps make step 2 much simpler, since the tree structure to navigate can be made far easier than the full XML document structure. I've also been looking at making step 1 be simply reading in the document using a standard parser and getting to a DOM version of it. That makes it really easy to complete step 1, but it seems to complicate the traversal in step 2, and the main drawback is that I haven't been able to figure out a way to keep track of the original line numbers. They are being reported in case there is a parse error, but the situation I want to handle is when the document is syntactically (and semantically) correct, but the importer doesn't know how to handle the Collada feature that is configured in the correctly defined data. Another possible advantage of using a DOM could be that it would help me resolve references to other elements - I think, only I haven't been able to figure out how to do that yet. Should that be possible? Does anybody have any suggestions for how to approach this? Any help would be much appreciated. Cheers, Petter
