Andrea, I agree with your conclusion. The existing GML 3 encoder, configuration, and bindings target GML application schemas. This is the only type of complex feature encoding that has any test coverage, and thus the only type that can be assumed to work. Nonetheless, I think your schema was a GML application schema, and I was surprised by the amount of pain you had. I guess we have been sheltered by our working DataAccess, and have not experienced the pain of those trying to build complex features by hand via a programmatic API.
I can see the value of builders and retrofitting these onto the existing code base, but the cost of this work is yet to be estimated and is not included in any project plan. The early gt-sample-data-access tests (which do not depend on gt-app-schema) and their corresponding GeoServer tests still run. Kind regards, Ben. On 31/03/11 14:56, Andrea Aime wrote: > My conclusion working with complex features is that if app-schema store > fits the bill and the target schema follows the same rules as gml there is a > chance to put togheter somethin , otherwise one should > really assume complex features are not really there and plan accordingly. -- Ben Caradoc-Davies <[email protected]> Software Engineering Team Leader CSIRO Earth Science and Resource Engineering Australian Resources Research Centre ------------------------------------------------------------------------------ Create and publish websites with WebMatrix Use the most popular FREE web apps or write code yourself; WebMatrix provides all the features you need to develop and publish your website. http://p.sf.net/sfu/ms-webmatrix-sf _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
