On Tuesday 18 September 2007 18:58:49 Justin Deoliveira wrote: > >> 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. That's why I was trying to avoid the "complex" word. It seems to have a "high complexity" connotation. The community-schema datastore handles (or is meant to) FeatureTypes of arbitrary complexity. Yet what it does is not that complex yet. > > 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 :). Excellent. Agreed. So doing that means a schema mapping ui. And note I'm not trying to promote community-schema-ds. Doing what you propose for the simple case can be handled with a simple set of mapping strategies, and even with a mapping datastore simpler than community-schema-ds. That way it may still make sense to keep concerns separated. Note we're already doing that kind of stuff when we wrap a FeatureSource given the state of an ui check (say, force CRS?). Proposal is the same: let geoserver configure a mapping datastore to handle that and the encoder to encode what the datastore serves up. I would just like to have a single place where to look for a single bug :P I might be over-dimensioning the problem though?
Cheers, Gabriel > > > Cheers > > Andrea > > > > !DSPAM:4007,46ef952e164994901796417! ------------------------------------------------------------------------- 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
