[Geoserver-devel] GML3 bindings and community schemas

I have been working on GS 1.6.x / GT 2.4.x, and have tangled with a few GML3 binding overrides required to get community-schemas to work as expected for GeoSciML Testbed 3.

At some stage, community-schemas will need to be ported to the trunks of GS and GT. I am trying to understand how much this process will be helped by the changes to the feature/attribute model introduced in trunk (by Gabriel Roldán?).

(1) Are binding overrides principally necessary because of the wrapping required to support complex features in GS 1.6.x / GT 2.4.x?

(2) If so, does this mean that the new feature model will remove the need for (most) binding overrides?

(3) Will the GML3 bindings be regenerated for the new feature/attribute model? (I am an EMF ignoramus.)

Kind regards,

--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer, CSIRO Exploration and Mining
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia

Hi Ben,

Gabriel is probably better equipped to answer these questions but I will give it a shot.

Ben Caradoc-Davies wrote:

I have been working on GS 1.6.x / GT 2.4.x, and have tangled with a few GML3 binding overrides required to get community-schemas to work as expected for GeoSciML Testbed 3.

At some stage, community-schemas will need to be ported to the trunks of GS and GT. I am trying to understand how much this process will be helped by the changes to the feature/attribute model introduced in trunk (by Gabriel Roldán?).

(1) Are binding overrides principally necessary because of the wrapping required to support complex features in GS 1.6.x / GT 2.4.x?

The binding overrides are mostly necessary due to the fact the current gml bindings on trunk assume a flat simple model. I believe the bindings that Gabriel implemented removed this restriction.

(2) If so, does this mean that the new feature model will remove the need for (most) binding overrides?

Not sure... we could follow two approaches here:

1) Only have one set of gml bindings that handle complex and simple content.

2) Have two sets of bindings, 1 set for simple, 1 set for complex.

(3) Will the GML3 bindings be regenerated for the new feature/attribute model? (I am an EMF ignoramus.)

If we went with option 2 and broke out separate bindings for complex yes it would make sense to regenerate them.

Kind regards,

--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com

Hi Ben,

sorry for the late response.

On Wednesday 09 April 2008 03:33:15 am Ben Caradoc-Davies wrote:

I have been working on GS 1.6.x / GT 2.4.x, and have tangled with a few
GML3 binding overrides required to get community-schemas to work as
expected for GeoSciML Testbed 3.

At some stage, community-schemas will need to be ported to the trunks of
GS and GT. I am trying to understand how much this process will be
helped by the changes to the feature/attribute model introduced in trunk
(by Gabriel Roldán?).

(1) Are binding overrides principally necessary because of the wrapping
required to support complex features in GS 1.6.x / GT 2.4.x?

exactly

(2) If so, does this mean that the new feature model will remove the
need for (most) binding overrides?

yeah, that's what should happen

(3) Will the GML3 bindings be regenerated for the new feature/attribute
model? (I am an EMF ignoramus.)

Basically the overrides we're using should replace the current ones. ie, the
current ones operates on the Feature.getAttribute(..) returns actual value
paradigm, and the new FM does Feature.getAttribte(..) returns Attribute,
which is why we use overrides.

cheers,

Gabriel

Kind regards,

Gabriel Roldán wrote:

On Wednesday 09 April 2008 03:33:15 am Ben Caradoc-Davies wrote:
> (1) Are binding overrides principally necessary because of the wrapping
> required to support complex features in GS 1.6.x / GT 2.4.x?
exactly
>
> (2) If so, does this mean that the new feature model will remove the
> need for (most) binding overrides?
yeah, that's what should happen

Thanks very much for confirming that, Gabriel.

--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer, CSIRO Exploration and Mining
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia