[CITE-Forum] more wfs 1.1 fixes

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


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

Hi Justin,

1. To avoid remote schema references I repaced all there 1.0.0 style
schema files with the complete schemas from OGC schema locations. I've
just seen that I did not remove the old schema files. I have done this
now.

2. Nice, that you found that one. I will do a fix.

3. As mentioned in 1 the references are correct, because I replaced
the schema files.

Regards

Sebastian


Am 06.06.2012 07:08, schrieb Justin Deoliveira:
> Ok, I think i have this sorted out now. But are still some typos in
> the wfs 1.1.0 trunk scripts I believe. I have attached a patch.
> Here is a summary of the changes:
> 
> 1. resources/xsd/ogc/ows/1.0.0/ows-1.0.0.xsd
> 
> There is still a reference to the old "xlink:simpleLink", which in
> the new schema is "xlink:simpelAttrs"
> 
> 
> 2. resources/xsd/w3c/xlink/1999/xlink.xsd
> 
> The schemaLocation attribute for the xml schema is missing a slash.
> This is what was causing the failure "could not find attribute
> xml:lang ..."
> 
> 
> 3. src/parsers.ctl
> 
> The references to the filter and ows schemas are wrong.
> "filter.xsd" -> "filter-1.1.0.xsd" and "ows.xsd" ->
> "ows-1.0.0.xsd".
> 
> 
> On Tue, Jun 5, 2012 at 9:36 AM, Justin Deoliveira
> <jdeolive at opengeo.org>wrote:
> 
>> 
>> 
>> 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.
>>> 
>>> 
>> 
>> 
>> -- 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+ZgACgkQq1hDh4aJykLY8QCeIog73rW07cX+PtYuLsSOcXJr
HXEAniYqPolgyUZABhFN1wzD89zkGL8R
=UN8Z
-----END PGP SIGNATURE-----


More information about the CITE-Forum mailing list