[geotk] Feature identifier retrieved from WFS prepended a '@' ??

[Emmanuel Blondel]

Thanks Martin,
Indeed i didn't think in possible collision between real property and 
attribute name. Now the explanations you provided are very clear, and 
it's necessary to distinguish real properties vs. attribute.
Anyway on our side it's not blocking.

I'm curious to know more about ongoing OGC discussions about API & 
especially policy aspects. Is it possible to follow somewhere the 
discussions?

Thanks again
Emmanuel


Le 11/03/2015 18:04, Martin Desruisseaux a écrit :
> Hello Emmanuel
>
> Thanks for asking. I should have posted earlier what is going on.
>
> We defined new Feature interfaces in GeoAPI [1][2], to be proposed to
> OGC as GeoAPI 3.1 (date undetermined - OGC is starting a discussion
> about what should be their policy about API). The new interfaces are
> based on ISO 19109 and hopefully simpler. We are slowly starting
> migration from the old to the new feature model.
>
> One difference is that the old model was a little bit XML-oriented, and
> distinguished between whether an information was a "XML attribute" or a
> "XML value". The new model is more abstract and does not distinguish
> such XML-specific details. We were thinking about applying a naming
> convention but I'm not sure if this is done (Johann would know better).
>
> An other issue is that we wanted to distinguish "real property" from
> "generated property". The idea is to prefix "generated property" with
> "@" to make them look like annotations. One goal was to avoid name
> collision: maybe the feature has a real "fid" property which has nothing
> to do with identifiers, so adding a "@" prefix for everything generated
> would hopefully avoid collision (a little bit like the Java compiler
> adding the "$" prefix in front of generated variable names).
>
> The new ISO 19109 model has the concept of "operation", which we are
> hopping to apply to the "@fid" attribute: if a real identifier already
> exists in the feature, the "@fid" attribute would be an operation that
> just delegate to the existing property. Otherwise the "@fid" attribute
> would be an operation generating an identifier.
>
> Do you think it would be okay?
>
>      Martin
>
>
> [1] http://jira.codehaus.org/browse/GEO-229
> [2]
> http://www.geoapi.org/snapshot/javadoc/org/opengis/feature/package-summary.html
>
>
> Le 11/03/15 16:40, Emmanuel Blondel a écrit :
>> I'm also wondering if it is correct to add this 'fid' as part of the
>> featureType by default, as it is not explicitely part of the WFS
>> DescribeFeatureType response (except maybe if we consider super
>> properties?)
>>
>> Le 11/03/2015 16:10, Emmanuel Blondel a écrit :
>>> Hello,
>>>
>>> I'm using JAXPStreamFeatureReader and JAXBFeatureTypeReader to read
>>> WFS data.
>>> Until now everything worked well (WFS 1.0.0 / 1.1.0), now testing i
>>> see i get the "fid" taken from the xml attribute of the same name.
>>> Strangely the featureType retrieved prepends "fid" with "@" -> "@fid"
>>> (i believe related code is
>>> https://github.com/Geomatys/geotoolkit/blob/master/modules/jaxp-xml-parser/geotk-jaxp-gml/src/main/java/org/geotoolkit/feature/xml/jaxb/JAXBFeatureTypeReader.java#L748).
>>> I'm just wondering if it's correct behavior.
>>> It's good to have access to the feature identifier, but shouldn't we
>>> rather expect to have the exact attribute name? (with no '@'). What
>>> do you think? or is there a particular reason that requires this naming?
>>>
>>> Thanks in advance
>>>
>>> Bests,
>>> Emmanuel
> _______________________________________________
> Geotoolkit mailing list
> Geotoolkit at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/geotoolkit

-- 
*Emmanuel Blondel*
International Consultant | CEO
/Geographic Information Systems in Agronomy, Environment, Fishery & 
Marine Sciences/
41, Avenue du Vacayrial
81370 Saint Sulpice la Pointe, France
Tel: +33 (0) 6 45 97 87 52
Email: emmanuel.blondel1 at gmail.com <mailto:emmanuel.blondel1 at gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/geotoolkit/attachments/20150311/cad83bf2/attachment.html>