Hi Petter, On the XPointer issue, general XPointer processing requires hooking into the source-level XML. Depending on how much effort you're willing to put into this, it'd be possible to create an XPointer-aware IXMLReader implementation, which could wrap another IXMLReader and apply an XPointer expression to screen the view of the document seen by the user. >From the little I've seen of XPointer it seems like that would be fairly easy, since XPointer That would allow you to only unmarshal the portion of a document which matches an XPointer expression, without reading the whole document into a DOM (which is relatively slow, and generally consumes a lot more memory than an unmarshalled data structure).
Error reporting, as you mentioned, should be fairly easy with JiBX. I don't know how the format is structured, but if there's some specific level in the data where you're likely to encounter unimplemented features you can add hooks to the binding which will let you report the missing features without killing the unmarshalling. Adding new features should also be easy, especially if these features use unique element names and corresponding unique Java data structures. It that's the case you can simply add new <mapping> definitions for features over time. I'm not sure what else to add, but if you have questions about how to implement parts of this ask away and I'll try to help. - Dennis Dennis M. Sosnoski SOA and Web Services in Java Training and Consulting http://www.sosnoski.com - http://www.sosnoski.co.nz Seattle, WA +1-425-939-0576 - Wellington, NZ +64-4-298-6117 Petter Måhlén wrote: > 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 > <http://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 > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > ------------------------------------------------------------------------ > > _______________________________________________ > jibx-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/jibx-users > ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ jibx-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jibx-users
