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

Reply via email to