The WFS 2.0 proposal has been sitting for over a week now. I would like to push this forward by calling for a vote if there is no more feedback. Or gather more feedback / patch review in order to drive it closer to a vote. Thanks, I realize it is a very large amount to review but at the same time I fear if we leave it sitting for too long the work will grow stale and further from being committed.
I had a chance to review and work with the WFS 2 stuff while we worked
on the versioning prototype and I'm comfortable with it. The proposal
looks also well written and to the point.
Have my +1 and congrats on the good work.
Gabriel
On Sat, Oct 22, 2011 at 2:18 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:
Hi all,
The WFS 2.0 proposal has been sitting for over a week now. I would like to
push this forward by calling for a vote if there is no more feedback. Or
gather more feedback / patch review in order to drive it closer to a vote.
Thanks, I realize it is a very large amount to review but at the same time I
fear if we leave it sitting for too long the work will grow stale and
further from being committed. http://geoserver.org/display/GEOS/GSIP+61+-+WFS+2.0
-Justin
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@anonymised.com Self-Assessment and learn
about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
--
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.
Speaking of going stale; is their any exposure in GeoServer to the ResourceId change that I expect to sort out on Monday on the GeoTools side? Or is just updating the bindings going to be enough …
–
Jody Garnett
On Sunday, 23 October 2011 at 3:18 AM, Justin Deoliveira wrote:
Hi all,
The WFS 2.0 proposal has been sitting for over a week now. I would like to push this forward by calling for a vote if there is no more feedback. Or gather more feedback / patch review in order to drive it closer to a vote. Thanks, I realize it is a very large amount to review but at the same time I fear if we leave it sitting for too long the work will grow stale and further from being committed.
–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@anonymised.com Self-Assessment and learn
about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev
The WFS 2.0 proposal has been sitting for over a week now. I would like to push this forward by calling for a vote if there is no more feedback. Or gather more feedback / patch review in order to drive it closer to a vote. Thanks, I realize it is a very large amount to review but at the same time I fear if we leave it sitting for too long the work will grow stale and further from being committed.
I added my +1 to the website; and gathered up the others from this thread.
Jody Garnett
On Sunday, 23 October 2011 at 3:18 AM, Justin Deoliveira wrote:
Hi all,
The WFS 2.0 proposal has been sitting for over a week now. I would like to push this forward by calling for a vote if there is no more feedback. Or gather more feedback / patch review in order to drive it closer to a vote. Thanks, I realize it is a very large amount to review but at the same time I fear if we leave it sitting for too long the work will grow stale and further from being committed.
–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@anonymised.com Self-Assessment and learn
about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev
Outstanding work, Justin. This is so huge that the only way to understand it is to commit it to trunk and see how it works in the wild. It will take some time to digest all the implications. I am sure users will find some gotchas, but this is certainly a step in the right direction.
On 23/10/11 01:18, Justin Deoliveira wrote:
Hi all,
The WFS 2.0 proposal has been sitting for over a week now. I would like to push this forward by calling for a vote if there is no more feedback. Or gather more feedback / patch review in order to drive it closer to a vote. Thanks, I realize it is a very large amount to review but at the same time I fear if we leave it sitting for too long the work will grow stale and further from being committed.
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre
Thanks Ben. Actually just running the tests last minute I found a test failure in app-schema that I think requires some more discussion. It has to do with how DescribeFeatureType deals with schemas that contain types from different namespaces. In the past the behaviour was to create a schema with no target namespace that contain only imports… pointing to the types from the various namespaces.
However with WFS 2.0 one of the compliance tests requires that we actually create a schema with a target namespace for the first type referenced… and create imports only for the types in the other namespaces. Which leads to a failure in the following app-schema tests:
So I wanted to get your feedback first before going and changing any test assertions. How do you think we should proceed? Should we change the test assertion to allow for the new wfs 2.0 style… or should we change the code to only adopt the new behaviour when we are responding to a wfs 2.0 DescribeFeatureType? I am thinking the latter is probably safest just in terms of backward compatibility… but wanted to hear your take.
Outstanding work, Justin. This is so huge that the only way to understand it is to commit it to trunk and see how it works in the wild. It will take some time to digest all the implications. I am sure users will find some gotchas, but this is certainly a step in the right direction.
On 23/10/11 01:18, Justin Deoliveira wrote:
Hi all,
The WFS 2.0 proposal has been sitting for over a week now. I would like to push this forward by calling for a vote if there is no more feedback. Or gather more feedback / patch review in order to drive it closer to a vote. Thanks, I realize it is a very large amount to review but at the same time I fear if we leave it sitting for too long the work will grow stale and further from being committed.
–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
–
Ben Caradoc-Davies Ben.Caradoc-Davies@anonymised.com
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre
–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
I have started fixing this test. I say let us go to the WFS-2.0-compatible form for consistency (the old namespace choice was arbitrary). Backwards compatibility is not a concern: the Awful Truth is that app-schema clients are unlikely to ever make a DescribeFeatureType request. They already have all the schemas, and the WFS GetFeature response encodes their canonical URLs. I don't think any client exists that both discovers feature types and supports complex feature types. Better that we get WFS 2.0 working and make WFS 1.1 DescribeFeatureType consistent with WFS 2.0 before anyone relies on the old behaviour.
More problematic is that, once the test is fixed, it picks up a duplicate include in one DescribeFeatureType response. I am investigating, and may need to submit a patch for FeatureTypeSchemaBuilder.
As an aside, I see that GET URLs now require version=1.1.0. Why is this? Is 2.0 the new WFS default? Or are we just promoting interoperability? And why are POST requests immune?
Kind regards,
Ben.
On 25/10/11 04:14, Justin Deoliveira wrote:
Thanks Ben. Actually just running the tests last minute I found a test failure in app-schema that I think requires some more discussion. It has to do with how DescribeFeatureType deals with schemas that contain types from different namespaces. In the past the behaviour was to create a schema with no target namespace that contain only imports... pointing to the types from the various namespaces.
However with WFS 2.0 one of the compliance tests requires that we actually create a schema with a target namespace for the first type referenced... and create imports only for the types in the other namespaces. Which leads to a failure in the following app-schema tests:
So I wanted to get your feedback first before going and changing any test assertions. How do you think we should proceed? Should we change the test assertion to allow for the new wfs 2.0 style... or should we change the code to only adopt the new behaviour when we are responding to a wfs 2.0 DescribeFeatureType? I am thinking the latter is probably safest just in terms of backward compatibility... but wanted to hear your take.
-Justin
--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre
Thanks for the input… but I wonder about other clients that do parse describe feature type… one would hope that people don’t rely on the structure but you never know. I guess we can wait and see.
Regarding adding of the version=1.1.0 parameter… simply put most existing test cases (in and out of app-schema) were not written to work with wfs 2.0 / gml 3.2 so rather than work on porting all tests to wfs 2.0 I simply added the version 1.1.0. Although many did seem ok with wfs 2.0 output so i left those be.
I fear that if i had to instead rewrite all existing tests to work with wfs 2.0 output that well… we would never see wfs 2.0 land on trunk
I have started fixing this test. I say let us go to the WFS-2.0-compatible form for consistency (the old namespace choice was arbitrary). Backwards compatibility is not a concern: the Awful Truth is that app-schema clients are unlikely to ever make a DescribeFeatureType request. They already have all the schemas, and the WFS GetFeature response encodes their canonical URLs. I don’t think any client exists that both discovers feature types and supports complex feature types. Better that we get WFS 2.0 working and make WFS 1.1 DescribeFeatureType consistent with WFS 2.0 before anyone relies on the old behaviour.
More problematic is that, once the test is fixed, it picks up a duplicate include in one DescribeFeatureType response. I am investigating, and may need to submit a patch for FeatureTypeSchemaBuilder.
As an aside, I see that GET URLs now require version=1.1.0. Why is this? Is 2.0 the new WFS default? Or are we just promoting interoperability? And why are POST requests immune?
Kind regards,
Ben.
On 25/10/11 04:14, Justin Deoliveira wrote:
Thanks Ben. Actually just running the tests last minute I found a test failure in app-schema that I think requires some more discussion. It has to do with how DescribeFeatureType deals with schemas that contain types from different namespaces. In the past the behaviour was to create a schema with no target namespace that contain only imports… pointing to the types from the various namespaces.
However with WFS 2.0 one of the compliance tests requires that we actually create a schema with a target namespace for the first type referenced… and create imports only for the types in the other namespaces. Which leads to a failure in the following app-schema tests:
So I wanted to get your feedback first before going and changing any test assertions. How do you think we should proceed? Should we change the test assertion to allow for the new wfs 2.0 style… or should we change the code to only adopt the new behaviour when we are responding to a wfs 2.0 DescribeFeatureType? I am thinking the latter is probably safest just in terms of backward compatibility… but wanted to hear your take.
-Justin
–
Ben Caradoc-Davies Ben.Caradoc-Davies@anonymised.com
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre
–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
I think I answered my version question by reading the last paragraph of GSIP 61, in which you point out that GeoServer follows OGC policy and will default to WFS 2.0. Most of the app-schema tests are very specific to particular schemas and will be left on WFS 1.1 / GML 3.1 with a &version=1.1.0 option.
The FeatureTypeSchemaBuilder fix was to remove an unwarratned assumption by treating includes the same as imports until the moment they are added to the schema (i.e. the same duplicate removal logic). Once that is done, it is all good.
Thanks for the input... but I wonder about other clients that do parse describe feature type... one would hope that people don't rely on the structure but you never know. I guess we can wait and see.
Regarding adding of the version=1.1.0 parameter... simply put most existing test cases (in and out of app-schema) were not written to work with wfs 2.0 / gml 3.2 so rather than work on porting all tests to wfs 2.0 I simply added the version 1.1.0. Although many did seem ok with wfs 2.0 output so i left those be.
I fear that if i had to instead rewrite all existing tests to work with wfs 2.0 output that well... we would never see wfs 2.0 land on trunk
--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre
I think I answered my version question by reading the last paragraph of GSIP 61, in which you point out that GeoServer follows OGC policy and will default to WFS 2.0. Most of the app-schema tests are very specific to particular schemas and will be left on WFS 1.1 / GML 3.1 with a &version=1.1.0 option.
The FeatureTypeSchemaBuilder fix was to remove an unwarratned assumption by treating includes the same as imports until the moment they are added to the schema (i.e. the same duplicate removal logic). Once that is done, it is all good.
Thanks for the input… but I wonder about other clients that do parse describe feature type… one would hope that people don’t rely on the structure but you never know. I guess we can wait and see.
Regarding adding of the version=1.1.0 parameter… simply put most existing test cases (in and out of app-schema) were not written to work with wfs 2.0 / gml 3.2 so rather than work on porting all tests to wfs 2.0 I simply added the version 1.1.0. Although many did seem ok with wfs 2.0 output so i left those be.
I fear that if i had to instead rewrite all existing tests to work with wfs 2.0 output that well… we would never see wfs 2.0 land on trunk
–
Ben Caradoc-Davies Ben.Caradoc-Davies@anonymised.com
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre
–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
Great, thanks Ben! With that I will get the work committed later on in the day.
--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre
A rat indeed I indeed can replicate this locally and can look into it. I am at a client site for most of the day but will attempt to work on this later today.
On Tue, Oct 25, 2011 at 8:28 AM, Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com.> wrote:
Great, thanks Ben! With that I will get the work committed later on in the day.
–
Ben Caradoc-Davies Ben.Caradoc-Davies@anonymised.com
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre
–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
Justin … I waited so long since I really wanted to have some more time to read the proposal deeply and better understand the progresses … unfortunately didn’t found yet much time to take more than a superficial look at the stuff, but also don’t want absolutely to block your work for this absolutely important upgrade of GeoServer.
So my +1 as PSC member, without no much help in terms of feedbacks on architectural and development aspects or concerns.
Alessio.
Ing. Alessio Fabiani
Founder / CTO GeoSolutions S.A.S.
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
A rat indeed I indeed can replicate this locally and can look into it. I am at a client site for most of the day but will attempt to work on this later today.
Great, thanks Ben! With that I will get the work committed later on in the day.
–
Ben Caradoc-Davies Ben.Caradoc-Davies@anonymised.com
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre
–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@anonymised.com Self-Assessment and learn
about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev
