[CITE-Forum] more wfs 1.1 fixes

Justin Deoliveira jdeolive at opengeo.org
Tue Jun 5 11:36:17 EDT 2012


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:
>
>> -----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.
>>
>> 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
>>
>> - --
>> 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-----
>> _______________________________________________
>> 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.
>
>


-- 
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengeospatial.org/pipermail/cite-forum/attachments/20120605/d14b4874/attachment-0001.htm>


More information about the CITE-Forum mailing list