Rob Atkinson wrote: > it would be great for the current round of development to be able to > propose changes if needed to the realtively-new-and-untested ISO > Feature interfaces in a more flexible environment than the stable > components.
Martin, we would very much like to change GeoAPI so that it can support XSD complexType with simpleContent. At the moment, we are stuck with an Ugly Hack: smuggling the simple content in a fake property. I am yet to write the encoder to unpack this mess. GeoAPI 2.2-SNAPSHOT cannot represent a XSD complexType with simpleContent. See the discussion on geotools-devel in October 2008: http://n2.nabble.com/ComplexAttribute-with-simpleContent-in-GeoAPI-2.2-td1959805.html The obvious solution is to use the ComplexAttribute value to store the content, that is, do not narrow the return type of getValue() (inherited from Property). Why should there be two ways of getting the properties? Do not bind ComplexAttribute to a container. Any GeoAPI changes that make it easier to change would be welcomed. Kind regards, -- Ben Caradoc-Davies <[email protected]> Software Engineer, CSIRO Exploration and Mining Australian Resources Research Centre 26 Dick Perry Ave, Kensington WA 6151, Australia ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
