[CITE-Forum] more wfs 1.1 fixes

Sebastian Goerke goerke at lat-lon.de
Wed Jun 6 02:40:06 EDT 2012


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

Hi Justin,

I don't know how Geoservers implementation deals with xlink
references. Our test instance of deegree had no need to change
references for passing the wfs 1.1.0 tests.

Regards

Sebastian

Am 05.06.2012 17:36, schrieb Justin Deoliveira:
> On Tue, Jun 5, 2012 at 8:32 AM, Justin Deoliveira
> <jdeolive at opengeo.org>wrote:
> 
>> Hi Sebastian,
>> 
>> On Tue, Jun 5, 2012 at 1:03 AM, Sebastian Goerke
>> <goerke at lat-lon.de>wrote:
>> 
> 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.
> 
> Great.
>>> 
> 
> 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.
> 
>>> 
>>> Ok... i am at a loss on this one. Can you provide any guidance
>>> on how you are making it work? From what I can tell this is not
>>> a geoserver issue. In the past I ran into this same issue and
>>> it had to do with xml.xsd (where xml:lang is defined) not being
>>> downloadable.
>>> 
> 
>> Sorry... this was my misunderstanding (well really just more
>> forgetting) that the new xlink schema changes are in play here...
>> so does this mean we have to reference the new schemas in order
>> to property validate?
> 
>>> 
>>> At the moment this is a blocker for me.
>>> 
> 
> 
> 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.
> 
>>> 
>>> Right, but what I am saying is that I don't think the fixes are
>>> valid. As far as I know the only delimiters for an http query
>>> string are "?" and "&". Is there somewhere you can point me in
>>> the http spec that says otherwise? So as I see it even putting
>>> version at the beginning of the query string still makes it
>>> impossible to parse it. In 9.2 the request:
>>> 
>>> version=1.1.0#request=GetCapabilities,service=WFS
>>> 
>>> I would think should be parsed into teh following key value
>>> pairs:
>>> 
>>> "version" : "1.1.0#request=GetCapabilities,service=WFS"
>>> 
>>> Again if I am missing something in the http spec I apologize.
>>> 
>>> 
> 4. DescribeFeatureType tc4.4
> 
> Seems to solve the problem regarding the version issues.
> 
> 
> 5. GetFeature tc23.4
> 
> same as 4
> 
> 
> Cool.
>>> 
>>> 
> 6. GetFeature tc44.1
> 
> We will have a further look for that and check your patch in, if
> it seems to solve the problem.
> 
> Great.
>>> 
> 
> 7. LockFeature invalid-request
> 
> Ok, that was just fixed for r9 tag. I will fix it for trunk also.
> 
>>> 
>>> Great.
>>> 
>>> Thanks again.
>>> 
> 
> 
> 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
>
>>>>> 
>>> _______________________________________________ CITE-Forum
>>> mailing list CITE-Forum at lists.opengeospatial.org 
>>> https://lists.opengeospatial.org/mailman/listinfo/cite-forum
>>> 
>> 
>> 
>> 
>> -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise
>> support for open source geospatial.
>> 
>> 
> 
> 

- -- 
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/O+0UACgkQq1hDh4aJykKGAACgnkSa+OEsL37Hga60JEx9/pwU
OucAn2pMri17txAER/Jf119zmBlxkNwR
=fXl3
-----END PGP SIGNATURE-----


More information about the CITE-Forum mailing list