Hi Ben; see my other reply that is more clear :-)

As for the actual LocationPropertyType it is a choice between several
things as I mentioned above. An actual Geometry or a magic string or
whatever.

So why should we not remove the intermediate GeoAPI object? It adds nothing. It is a GML encoding artifact.

Ben I am not sure what you are trying to get rid of here?
- "location"
- "LocationPropertyType"

Or what?

I am trying to draw a distinction between GeoAPI and GML. I do not know any reason to follow the GML pattern in GeoAPI.

Okat so this is where I am stuck communicating; I find many things to be odd and complicated about GML and am trying to sort out which odd and complicated thing you would like to try and clean up :-)

Are you referring to:
- the use of gml:location which is a useless thing that just provides an <element name="location" type="gml:LocationPropertyType">?

I think we can remove this; ie it should show up in our model as a single attribute descriptor "location" of type LocationPropertyType

- the use of gml:LocationPropertyType as an annoyance between us and a gml:Geometry

I don't think we can get rid of this as they seem to be using it to have either a geometry or a string or whatever ...

In GeoAPI we have direct access to type information, so we do not need to follow the GML pattern, which exists to encode type information. It makes the bindings more complicated than they need to be. Furthermore, it prevents us from treating associations and attributes consistently, because association references get smuggled as attributes on property types, while attributes are inline.

So if we can use "instanceof" we may be able to get rid of gml:LocationPropertyType?
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Reply via email to