Suppose I have an XML structure <foo> mapped in binding #1 to class A and this is used in some applications.
Now I have a new application which uses a new extended version of the previous XML structure <foo2> that contains the same stuff as <foo> but also allows a some additional elements, and I want to defined a new binding #2 that can <include> binding #1 to reuse the existing stuff and then add the additional elements to the <foo2> XML structure. It seems like this can work but only if the names "foo" and "foo2" are different. This is because two mappings for the same class can't have the same XML element name (because JiBX wouldn't know which one to use when unmarshalling). What would be nice is if this constraint were relaxed as follows: in the case of any conflict, the importing file wins over the imported file (if there's no import relationship, binding fails). Or, more generally there could be an (implicit or explicit) priority parameter associated with each mapping: for example, consider how XSL <import> statements automatically affect template priorities. This would allow the first application and the second application to both use <foo> as the element name, and for binding #1 to be efficiently reused by <include>'ing it. The way it is now you have to separate out an abstract mapping for <foo>.. which you think would be OK, but it's not when <foo> is nested deeply inside a bunch of other XML tags, because then you discover that you have to do this recursively for all the containing structures as well, basically duplicating the entire XML hierarchy and forcing abstract definitions for every structure. Is this change reasonable and/or feasible? Thanks, -Archie -- Archie L. Cobbs
------------------------------------------------------------------------------ This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev
_______________________________________________ jibx-users mailing list jibx-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jibx-users
