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 ------------------------------------------------------------------------------ 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
