Hi Justin, I did an experiment and hacked xsd-gml3 to use a gml3.2 test case, and it looks like the bindings for gml 3.1.1 are basically re-usable for gml3.2 support. I know we'll need a new binding (gml:identifier, basically a gml:name)
it seems that its the tests which are most heavily bound to gml3.1.1 flavour I'd like your advice as how best to proceed... do we create a gml3-common - make gml3 extend it and have a gml3_2 extend it. Most of the tests would be in the gml3-common, with the config set ups and mock data in the specific flavours? I suppose I could just clone gml3 to gml3_2 and we can refactor later - but I hate creating such an obvious mess of redundant code. Maybe GML3.1.1 will die on the vine and it wont be such a big deal. Or do you have a better idea? Rob ------------------------------------------------------------------------- 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=/ _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
