Thanks for your response Jody. I've posted my message on the standards
mailing list.
Met vriendelijke groet,
Alex van den Hoogen
-------------------------------------
*Geodan*
Buitenhaven 27-A
5211 TP 's-Hertogenbosch (NL)
T +31 (0)73 - 5484 149
E [email protected]
www.geodan.nl | disclaimer <http://www.geodan.nl/disclaimer/>
-------------------------------------
2014-12-09 18:07 GMT+01:00 Jody Garnett <[email protected]>:
> I would seek clarification from the other open-source projects on
> [email protected].
>
> Sounds like a muddle.
> On Tue, Dec 9, 2014 at 3:40 AM Alex van den Hoogen | Geodan <
> [email protected]> wrote:
>
>> Dear all,
>>
>> I'm still curious about this issue regarding WFS 2.0.0. I've discussed
>> and read the standard with some of my colleagues and we are quite confused
>> regarding this specific issue.
>>
>> First and foremost, in Geoserver the current implementation with an empty
>> ReturnTypeFeature element is considered invalid. This is because this
>> element is of the type QName, which must have contents according to the
>> technical (XML) standards.
>>
>> However, we feel this is contradicted by the WFS 2.0.2 (most recent)
>> standards document of the OGC. In chapter 14.3.4 Response (of
>> ListFeatureQueries) it states that ReturnFeatureType must appear one or
>> more times in the response. But this section also refers to 14.2 for a more
>> extensive describtion of ReturnFeatureType.
>>
>> And here is where it gets really complicated. Strictly speaking 14.2
>> doesn't mention ReturnFeatureType but only the plural form
>> ReturnFeatureTypes. So, if we treat those two elements as different items,
>> we can conclude that there is no additional information regarding
>> ReturnFeatureType and it just has to comply to xsd:QName, nothing more,
>> nothing less.
>>
>> But if we treat both those elements as one, than ReturnFeatureType(s) is
>> refered to in 14.2.2.5.2. Where a corrigendum is made in the form of: "If
>> the value of the returnFeatureTypes parameter is an empty string, this
>> indicates that the stored query can return features of any type that the
>> service offers.". Which clearly states that ReturnFeatureType can have an
>> empty string and thus be an empty element. Only does this clash with
>> xsd:QName and makes the response technically invalid XML.
>>
>> Also note that in the change request (CR 11-100) that is relevant to this
>> change from 2.0.0 to 2.0.2, the submitter specifically mentions
>> returnFeatureType (the singular word) and not returnFeatureTypes (plural).
>>
>> Coming back to the issue, you can probably see that we are quite confused
>> regarding this issue, not even bringing up the fact if GeoServer should
>> support WFS 2.0.0 or WFS 2.0.2. In which I guess 2.0.2 would be a better
>> fit.
>>
>> Currently my question lies in whether what the GeoServer community thinks
>> about this issue and maybe what we can do with it? Also what the most
>> practical thing would be for GeoServer itself and still complying to the
>> standards (whether 2.0.0 or 2.0.2)?
>>
>> Additional links:
>> - WFS 2.0.2: http://docs.opengeospatial.org/is/09-025r2/09-025r2.html
>> - WFS 2.0.0 CR 11-100: https://portal.opengeospatial.org/files/45707
>> (pdf)
>>
>> Thanks and kind regards,
>> Alex van den Hoogen
>>
>> -------------------------------------
>> *Geodan*
>> Buitenhaven 27-A
>> 5211 TP 's-Hertogenbosch (NL)
>>
>> E [email protected]
>>
>> www.geodan.nl | disclaimer <http://www.geodan.nl/disclaimer/>
>> -------------------------------------
>>
>> 2014-11-18 10:49 GMT+01:00 Andrea Aime <[email protected]>:
>>
>>> On Tue, Nov 18, 2014 at 10:04 AM, Alex van den Hoogen | Geodan <
>>> [email protected]> wrote:
>>>
>>>> Currently I'm quite unsure about this issue. Either GeoServer complies
>>>> with the 2.0.2 standard of WFS, which is the current leading standard. But
>>>> than there is a slight inconsistency about the version number.
>>>>
>>>> On the other hand, fixing this issue for every FeatureType is, I think,
>>>> extremely difficult and would affect quite a lot of code.
>>>>
>>>> That's why I'm curious about other opinions. Especially from Justin and
>>>> Andrea.
>>>>
>>>
>>> Never looked into stored queries, so ... I don't have an opinion ready,
>>> I'd have to study the spec.
>>>
>>> Cheers
>>> Andrea
>>>
>>> --
>>> ==
>>> GeoServer Professional Services from the experts! Visit
>>> http://goo.gl/NWWaa2 for more information.
>>> ==
>>>
>>> Ing. Andrea Aime
>>> @geowolf
>>> Technical Lead
>>>
>>> GeoSolutions S.A.S.
>>> Via Poggio alle Viti 1187
>>> 55054 Massarosa (LU)
>>> Italy
>>> phone: +39 0584 962313
>>> fax: +39 0584 1660272
>>> mob: +39 339 8844549
>>>
>>> http://www.geo-solutions.it
>>> http://twitter.com/geosolutions_it
>>>
>>> *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*
>>>
>>> Le informazioni contenute in questo messaggio di posta elettronica e/o
>>> nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
>>> loro utilizzo è consentito esclusivamente al destinatario del messaggio,
>>> per le finalità indicate nel messaggio stesso. Qualora riceviate questo
>>> messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
>>> darcene notizia via e-mail e di procedere alla distruzione del messaggio
>>> stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
>>> divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
>>> utilizzarlo per finalità diverse, costituisce comportamento contrario ai
>>> principi dettati dal D.Lgs. 196/2003.
>>>
>>>
>>>
>>> The information in this message and/or attachments, is intended solely
>>> for the attention and use of the named addressee(s) and may be confidential
>>> or proprietary in nature or covered by the provisions of privacy act
>>> (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
>>> Code).Any use not in accord with its purpose, any disclosure, reproduction,
>>> copying, distribution, or either dissemination, either whole or partial, is
>>> strictly forbidden except previous formal approval of the named
>>> addressee(s). If you are not the intended recipient, please contact
>>> immediately the sender by telephone, fax or e-mail and delete the
>>> information in this message that has been received in error. The sender
>>> does not give any warranty or accept liability as the content, accuracy or
>>> completeness of sent messages and accepts no responsibility for changes
>>> made after they were sent or for other risks which arise as a result of
>>> e-mail transmission, viruses, etc.
>>>
>>> -------------------------------------------------------
>>>
>>
>> ------------------------------------------------------------
>> ------------------
>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
>> with Interactivity, Sharing, Native Excel Exports, App Integration & more
>> Get technology previously reserved for billion-dollar corporations, FREE
>> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&;
>> iu=/4140/ostg.clktrk_______________________________________________
>> Geoserver-devel mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>
>
------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
