Hi Rob,
<snip> > > > in essence, we need to decide if we care about supporting deprecated > or removed stuff (an overly lax gml3.2), if so, what mechanism could > we use to catch such exceptions. Without knowing a lot about the specifics, i would say yes. My rationale being things like gml:MultiPolygon and gml:MultiLineString being deprecated. I have not seen a lot of GML that has made the jump to MultiSurface and MultiCurve. And GeoServer only outputs them when in strict "cite compliance" mode. > > There is a lot unimplemented in both GML 3.1 and therefore GML3.2, and > IMHO we need to look at published schemas in a systematic way to catch > the things we need, and the INSPIRE GML3.2 schemas is a very good > place to start - make sure we can support all these and we'll catch > stuff in both GML 3.1 and 3.2 I suspect. Agreed, we should look at the schemas and figure out what bindings we have, and what we don't. And what sort of java objects each binding would correspond to. > > > Can you explain how you'd propose organise the codebase? Bindings seem > good, nice handling of namespaces etc, but tests extend a GML3.1.1 > bound setup for. I'm happy to do the work, but want to be working to > a plan you are comfortable with, and I didnt see an obvious way of > extending the current implementation. > So I would say we create a new package in the gml3 module called "org.geootools.gml3.v3_2". Inside this directory there will be: * a new GMLConfiguration class which sets up the bindings custom to GML 3.2 * a new GML class which contains all the type and elements names for GML3, and also a reference to the actual gml.xsd file for 3.2. This class can be generated with the code generator. Then create another subpackage called "org.geotools.gml3.v3_2.bindings" where all the 3.2 specific bindings can live. -Justin > Rob > > > > > > > > On Wed, Nov 19, 2008 at 12:51 AM, Justin Deoliveira > <[EMAIL PROTECTED]> wrote: >> Hi Rob, >> >> Do we have a list of types between 3.1.1 and 3.2 which are different? >> Instead of creating a new module i think it might be best if we kept the new >> 3.2 binding in the same module, perhaps just a different package. W e can >> then create a new GMLConfiguration class for the new bindings. I think will >> suffice with a minimum amount of "clutter". >> >> So the question is how do we proceed with implementing the new bindings. You >> said alot of the 3.1 bindings can be reused, which is great. Are there any >> that can't be reused? >> >> -Justin >> >> Rob Atkinson wrote: >>> 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 >> >> -- >> Justin Deoliveira >> OpenGeo - http://opengeo.org >> Enterprise support for open source geospatial. >> -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. ------------------------------------------------------------------------- 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
