Hi Ben,
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 :)
On Tue, Oct 25, 2011 at 6:53 AM, Ben Caradoc-Davies
<[email protected]> wrote:
> Justin,
>
> 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:
>>
>> testDescribeFeatureType(org.**geoserver.test.**FeatureChainingWfsTest)
>>
>> 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 <[email protected]>
> 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@Cisco Self-Assessment and learn
about Cisco certifications, training, and career opportunities.
http://p.sf.net/sfu/cisco-dev2dev
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
