>>> >> I would say to stay simple and consistent. I.e. no hacking at the >> geoserver side to match an unqualified "name" attribute to "gml:name". >> Same for location, etc. >> Rationale: gml:name has its semantic, and might be different from the >> "name" attribute of a single db table. If a postgis, shapefile, etc >> table has a name attribute, encode it with the datastore provided >> namespace. This makes the encoding more straightforward and avoids the >> counter-hack when one actually don't want it to be encoded as gml:name. >> If you want a field from your table to be mapped as gml:name (and >> actually there's no need for the original att to be called name) you >> should be able of doing that and much more, which is what the >> community-schema datastore is for. Yeah I know its still in >> unsupported, yet I would say to keep the encoder straight forward and >> avoid hacking, there's a much better solution to map a legacy data >> structure to another one, legacy or not. >> > Gabriel, I totally agree with you in principle, yet there may be a > reason to keep that hack: I kind of remind > WFS cite tests looking for the gml:name property and willing to have it > mapped to some data column. > I may be totally off thought, Justin will know more. I can definitely see both sides here... I agree that a formal mapping is the "right" way to do it. However, for a simple case like I think that using a complex datastore may be overkill or an inconvenience. With the new feature model we should be able to support this case with regular datastores.
Ideally we would have a simple "schema editor" on the feature type editor page, similar to what we have now but be able to set things like namespace uri's for attributes, base types, etc... Just a thought, not sure if its a good one :). > > Cheers > Andrea > > !DSPAM:4007,46ef952e164994901796417! > -- Justin Deoliveira The Open Planning Project http://topp.openplans.org ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
