Gabriel Roldán ha scritto:
> On Monday 17 September 2007 17:26:41 Justin Deoliveira wrote:
>
>>>> So simpleFeature.getAttribute("name") would indeed match content created
>>>> with a "gml:name" (the gml prefix internally would of been matched
>>>> against a
>>>> NameImpl("http://schemas.opengis.net/gml/3.2.1/gml.xsd","name";).
>>>>
>>> Right, but if you're talking about SimpleFeature, I don't think
>>> SimpleFeature could extend from gml:Feature as gml:name has multiplicity
>>> 0..N, which makes it non simple by definition?
>>>
>> Good point Gabriel, you are correct. I am in agreement with Jody on this
>> one in that I think attribute names should be left unqualified, and
>> mapped on the encoding side. What are your thoughts?
>>
> 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.
Cheers
Andrea
-------------------------------------------------------------------------
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
