Rob Atkinson ha scritto: > GML3 handles decoding and encoding, so for community-schema-ds we need > the encoder bindings to be sensible, right? > > so does this mean that GML3 can only read simple features, and encode > simple features? Is this an arbitrary limitation (for some reason a > deliberate choice of bindings based on familiarity perhaps), > convenient temporary limitation (only simple features were implemented > at the time) or an artefact of a global search-replace and not > intended at all really?
A bit of the second and the third I'd say, the parser/encoder have been written on 2.4.x where no complex feature support is present at the API level, and none was added when switching to the new API. The idea of the feature model was to make complex feature possible, actually implementing complex feature usage in produces (datastores, xml parsers) and consumers (renderer, xml encoders) is up to whoever has the time and resources to make it happen. > If the encoder was smart enough to handle any feature, it wouldnt > matter if a simple feature was fed to it - it would just be a trivial > case. Well, only as long as it does not make the simple feature case much slower. 10% slower is ok, 2+ times slower is unacceptable. Cheers Andrea -- Andrea Aime OpenGeo - http://opengeo.org Expert service straight from the developers. ------------------------------------------------------------------------- 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
