[CITE-Forum] more wfs 1.1 fixes

Justin Deoliveira jdeolive at opengeo.org
Tue Jun 5 10:32:21 EDT 2012


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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengeospatial.org/pipermail/cite-forum/attachments/20120605/8e16eefa/attachment.htm>


More information about the CITE-Forum mailing list