<br><br><div class="gmail_quote">On Tue, Jun 5, 2012 at 8:32 AM, Justin Deoliveira <span dir="ltr"><<a href="mailto:jdeolive@opengeo.org" target="_blank">jdeolive@opengeo.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Hi Sebastian,<br><br><div class="gmail_quote"><div>On Tue, Jun 5, 2012 at 1:03 AM, Sebastian Goerke <span dir="ltr"><<a href="mailto:goerke@lat-lon.de" target="_blank">goerke@lat-lon.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
<br>
Hi Justin,<br>
<br>
thanks for your work on optimizing the tests.<br>
<br>
I have some comments on your issues:<br>
<br>
1. typo in build.xml<br>
<br>
Yes, you mentioned that in the email to me. I also checked that and<br>
your patch seems to solve this issue.<br>
<div><br></div></blockquote></div><div>Great. </div><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
<br>
2. issues with xlink schema references<br>
<br>
</div>Switching back to the old schema references will not help at this point.<br>
Regarding the new OGC xlink policy, it is necessary to use these new<br>
references from July on. We have to make them work with the trunk<br>
scripts. Our test installation on<br>
<a href="http://cite.lat-lon.de/deegree-compliance-tests-3.1.2/services/wfs110?service=WFS&request=GetCapabilities" target="_blank">http://cite.lat-lon.de/deegree-compliance-tests-3.1.2/services/wfs110?service=WFS&request=GetCapabilities</a><br>



<br>
solves all WFS 1.1.0 tests from trunk.<br></blockquote><div><br></div></div><div>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. </div>

</div></blockquote><div><br></div><div>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?</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote">
<div><br></div><div>At the moment this is a blocker for me. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
<div><br>
<br>
3. GetCapabilities tc9.2 and tc16.5<br>
<br>
</div></div><div>We had a short discussion about that via email. For tc16.5 this is<br>
already fixed in trunk. For tc9.2 I will check in your patch.<br>
</div></blockquote><div> </div><div>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:</div>


<div><br></div><div>  version=1.1.0#request=GetCapabilities,service=WFS</div><div><br></div><div>I would think should be parsed into teh following key value pairs:</div><div><br></div><div>"version" : "1.1.0#request=GetCapabilities,service=WFS"</div>


<div><br></div><div>Again if I am missing something in the http spec I apologize. </div><div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
4. DescribeFeatureType tc4.4<br>
<br>
Seems to solve the problem regarding the version issues.<br>
<br>
<br>
5. GetFeature tc23.4<br>
<br>
same as 4<br>
<br>
<br></blockquote></div><div>Cool.</div><div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
6. GetFeature tc44.1<br>
<br>
We will have a further look for that and check your patch in, if it<br>
seems to solve the problem.<br>
<br></blockquote></div><div>Great. </div><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
7. LockFeature invalid-request<br>
<br>
Ok, that was just fixed for r9 tag. I will fix it for trunk also.<br></blockquote><div><br></div></div><div>Great.</div><div><br></div><div>Thanks again. </div><div><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<br>
<br>
Regards<br>
<br>
Sebastian<br>
<br>
Am 05.06.2012 05:14, schrieb Justin Deoliveira:<br>
<div><div>> HI all,<br>
><br>
> I have updated to the latest version of the wfs 1.1.0 trunk tests.<br>
> Here are the issues i ran into.<br>
><br>
> 1. typo in build.xml<br>
><br>
> The build.xml files references an incorrect file. Patch attached.<br>
> build.xml.patch.<br>
><br>
> 2. issues with xlink schema references<br>
><br>
> The trunk tests still don't compile for me. There was a recent<br>
> commit that went in for this issue but I still don't think it is<br>
> fixed yet. I generated a diff of the trunk against the r9 tag and<br>
> attached the patch (xlink.patch). WIth this patch the tests are<br>
> actually runnable for me.<br>
><br>
> 3. GetCapabilities tc9.2 and tc16.5<br>
><br>
> These tests use malformed URL's to test a service exception, but<br>
> with the way they specify the version there is really no way to<br>
> really parse it out and recognize. For instance:<br>
><br>
> <baseUrl>#request=GetCapabilities,service=WFS,version=1.1.0<br>
><br>
> I don't how it is possible to infer the version by parsing a proper<br>
> query string. I think the version needs to be specified directly<br>
> after the query string delimiter. Like this:<br>
><br>
> <baseUrl>?version=1.1.0&<rest of malformed url><br>
><br>
> Patch attached (GetCapabiltiies.patch)<br>
><br>
> 4. DescribeFeatureType tc4.4<br>
><br>
> This test doesn't specify a version but asserts a wfs 1.1.0<br>
> response. Attached is a patch that changes the assertion to be more<br>
> lax and not actually validate agains the ows 1.0 schema. Instead<br>
> just checking the local name of the element.<br>
><br>
> 5. GetFeature tc23.4<br>
><br>
> Same fix as (4), no version specified but asserts the ows 1.0<br>
> exception schema. Patch attached.<br>
><br>
> 6. GetFeature tc44.1<br>
><br>
> Same as 5 and 6 but this assertion does tests against the exception<br>
> code and the locator attributes. Fix doesn't validate against the<br>
> ows 1.0 schema but still asserts the value of the exception code<br>
> and locator.<br>
><br>
> 7. LockFeature invalid-request<br>
><br>
> The test uses the GET, which I think should be a post request.<br>
> Patch attached.<br>
><br>
> Hope that all makes sense.<br>
><br>
> -Justin<br>
><br>
><br>
><br>
><br>
</div></div>> _______________________________________________ CITE-Forum mailing<br>
> list <a href="mailto:CITE-Forum@lists.opengeospatial.org" target="_blank">CITE-Forum@lists.opengeospatial.org</a><br>
> <a href="https://lists.opengeospatial.org/mailman/listinfo/cite-forum" target="_blank">https://lists.opengeospatial.org/mailman/listinfo/cite-forum</a><br>
<br>
- --<br>
l a t / l o n  GmbH<br>
Aennchenstrasse 19               53177 Bonn, Germany<br>
phone ++49 +228 18496-0          fax ++49 +228 18496-29<br>
<a href="http://www.lat-lon.de" target="_blank">http://www.lat-lon.de</a>            <a href="http://www.deegree.org" target="_blank">http://www.deegree.org</a><br>
<br>
-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v1.4.11 (GNU/Linux)<br>
Comment: Using GnuPG with Mozilla - <a href="http://enigmail.mozdev.org/" target="_blank">http://enigmail.mozdev.org/</a><br>
<br>
iEYEARECAAYFAk/Nrz4ACgkQq1hDh4aJykLCXQCdFxf9fIs/i7SRZZbdnCKS9H/P<br>
t8gAoKNPffGa+ins+4QwsLxbsV3PSobw<br>
=qebD<br>
-----END PGP SIGNATURE-----<br>
_______________________________________________<br>
CITE-Forum mailing list<br>
<a href="mailto:CITE-Forum@lists.opengeospatial.org" target="_blank">CITE-Forum@lists.opengeospatial.org</a><br>
<a href="https://lists.opengeospatial.org/mailman/listinfo/cite-forum" target="_blank">https://lists.opengeospatial.org/mailman/listinfo/cite-forum</a><br>
</blockquote></div></div></div><br><br clear="all"><div><div><div><br></div>-- <br><font face="'courier new', monospace">Justin Deoliveira</font><div><font face="'courier new', monospace">OpenGeo - <a href="http://opengeo.org" target="_blank">http://opengeo.org</a></font></div>


<div><font face="'courier new', monospace">Enterprise support for open source geospatial.</font></div><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><font face="'courier new', monospace">Justin Deoliveira</font><div><font face="'courier new', monospace">OpenGeo - <a href="http://opengeo.org" target="_blank">http://opengeo.org</a></font></div>

<div><font face="'courier new', monospace">Enterprise support for open source geospatial.</font></div><br>