[CITE-Forum] more wfs 1.1 fixes

Sebastian Goerke goerke at lat-lon.de
Tue Jun 5 03:03:38 EDT 2012


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Justin,

thanks for your work on optimizing the tests.

I have some comments on your issues:

1. typo in build.xml

Yes, you mentioned that in the email to me. I also checked that and
your patch seems to solve this issue.


2. issues with xlink schema references

Switching back to the old schema references will not help at this point.
Regarding the new OGC xlink policy, it is necessary to use these new
references from July on. We have to make them work with the trunk
scripts. Our test installation on
http://cite.lat-lon.de/deegree-compliance-tests-3.1.2/services/wfs110?service=WFS&request=GetCapabilities

solves all WFS 1.1.0 tests from trunk.


3. GetCapabilities tc9.2 and tc16.5

We had a short discussion about that via email. For tc16.5 this is
already fixed in trunk. For tc9.2 I will check in your patch.


4. DescribeFeatureType tc4.4

Seems to solve the problem regarding the version issues.


5. GetFeature tc23.4

same as 4


6. GetFeature tc44.1

We will have a further look for that and check your patch in, if it
seems to solve the problem.


7. LockFeature invalid-request

Ok, that was just fixed for r9 tag. I will fix it for trunk also.


Regards

Sebastian

Am 05.06.2012 05:14, schrieb Justin Deoliveira:
> HI all,
> 
> I have updated to the latest version of the wfs 1.1.0 trunk tests.
> Here are the issues i ran into.
> 
> 1. typo in build.xml
> 
> The build.xml files references an incorrect file. Patch attached. 
> build.xml.patch.
> 
> 2. issues with xlink schema references
> 
> The trunk tests still don't compile for me. There was a recent
> commit that went in for this issue but I still don't think it is
> fixed yet. I generated a diff of the trunk against the r9 tag and
> attached the patch (xlink.patch). WIth this patch the tests are
> actually runnable for me.
> 
> 3. GetCapabilities tc9.2 and tc16.5
> 
> These tests use malformed URL's to test a service exception, but
> with the way they specify the version there is really no way to
> really parse it out and recognize. For instance:
> 
> <baseUrl>#request=GetCapabilities,service=WFS,version=1.1.0
> 
> I don't how it is possible to infer the version by parsing a proper
> query string. I think the version needs to be specified directly
> after the query string delimiter. Like this:
> 
> <baseUrl>?version=1.1.0&<rest of malformed url>
> 
> Patch attached (GetCapabiltiies.patch)
> 
> 4. DescribeFeatureType tc4.4
> 
> This test doesn't specify a version but asserts a wfs 1.1.0
> response. Attached is a patch that changes the assertion to be more
> lax and not actually validate agains the ows 1.0 schema. Instead
> just checking the local name of the element.
> 
> 5. GetFeature tc23.4
> 
> Same fix as (4), no version specified but asserts the ows 1.0
> exception schema. Patch attached.
> 
> 6. GetFeature tc44.1
> 
> Same as 5 and 6 but this assertion does tests against the exception
> code and the locator attributes. Fix doesn't validate against the
> ows 1.0 schema but still asserts the value of the exception code
> and locator.
> 
> 7. LockFeature invalid-request
> 
> The test uses the GET, which I think should be a post request.
> Patch attached.
> 
> Hope that all makes sense.
> 
> -Justin
> 
> 
> 
> 
> _______________________________________________ CITE-Forum mailing
> list CITE-Forum at lists.opengeospatial.org 
> https://lists.opengeospatial.org/mailman/listinfo/cite-forum

- -- 
l a t / l o n  GmbH
Aennchenstrasse 19               53177 Bonn, Germany
phone ++49 +228 18496-0          fax ++49 +228 18496-29
http://www.lat-lon.de            http://www.deegree.org

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk/Nrz4ACgkQq1hDh4aJykLCXQCdFxf9fIs/i7SRZZbdnCKS9H/P
t8gAoKNPffGa+ins+4QwsLxbsV3PSobw
=qebD
-----END PGP SIGNATURE-----


More information about the CITE-Forum mailing list