<br><br><div class="gmail_quote">On Tue, Jun 5, 2012 at 11:33 PM, 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">
<div class="im">-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
<br>
Hi Justin,<br>
<br>
</div>1. To avoid remote schema references I repaced all there 1.0.0 style<br>
schema files with the complete schemas from OGC schema locations. I've<br>
just seen that I did not remove the old schema files. I have done this<br>
now.<br></blockquote><div><br></div><div>I still have issues.</div><div><br></div><div>Caused by: java.lang.Exception: Can't find resource xsd/ogc/ows/1.0.0/owsAll.xsd</div><div><span class="Apple-tab-span" style="white-space:pre">     </span>at com.occamlab.te.parsers.XMLValidatingParser.loadSchemaList(XMLValidatingParser.java:89)</div>
<div><span class="Apple-tab-span" style="white-space:pre">      </span>at com.occamlab.te.parsers.XMLValidatingParser.loadSchemaLists(XMLValidatingParser.java:110)</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>at com.occamlab.te.parsers.XMLValidatingParser.<init>(XMLValidatingParser.java:166)</div>
<div><span class="Apple-tab-span" style="white-space:pre">      </span>... 71 more</div><div><br></div><div><br></div><div>The parsers.ctl file still seems to be referencing schema files that don't exist, like owsAll.xsd and filter.xsd. If i remove all references to them i then get validation errors such as:</div>
<div><br></div><div><div>Error in call to extension function {public org.w3c.dom.NodeList com.occamlab.te.TECore.request(org.w3c.dom.Document,java.lang.String) throws java.lang.Throwable}: Exception in extension function java.lang.Exception: Error invoking parser {<a href="http://teamengine.sourceforge.net/parsers}XMLValidatingParser.GMLSF1">http://teamengine.sourceforge.net/parsers}XMLValidatingParser.GMLSF1</a></div>
<div>org.xml.sax.SAXParseException: src-resolve: Cannot resolve the name 'ows:ServiceType' to a(n) 'type definition' component.</div><div>      Test wfs:readiness-tests Failed</div></div><div><br></div><div>
<br></div><div>I am curious, are you actually able to run the trunk tests in there current state? Either the way i am configuring the scripts and the engine is very wrong or the tests are very broken it seems. </div><div>
<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
2. Nice, that you found that one. I will do a fix.<br>
<br>
3. As mentioned in 1 the references are correct, because I replaced<br>
the schema files.<br>
<br>
Regards<br>
<br>
Sebastian<br>
<br>
<br>
Am 06.06.2012 07:08, schrieb Justin Deoliveira:<br>
<div class="im">> Ok, I think i have this sorted out now. But are still some typos in<br>
> the wfs 1.1.0 trunk scripts I believe. I have attached a patch.<br>
> Here is a summary of the changes:<br>
><br>
> 1. resources/xsd/ogc/ows/1.0.0/ows-1.0.0.xsd<br>
><br>
> There is still a reference to the old "xlink:simpleLink", which in<br>
> the new schema is "xlink:simpelAttrs"<br>
><br>
><br>
> 2. resources/xsd/w3c/xlink/1999/xlink.xsd<br>
><br>
> The schemaLocation attribute for the xml schema is missing a slash.<br>
> This is what was causing the failure "could not find attribute<br>
> xml:lang ..."<br>
><br>
><br>
> 3. src/parsers.ctl<br>
><br>
> The references to the filter and ows schemas are wrong.<br>
> "filter.xsd" -> "filter-1.1.0.xsd" and "ows.xsd" -><br>
> "ows-1.0.0.xsd".<br>
><br>
><br>
> On Tue, Jun 5, 2012 at 9:36 AM, Justin Deoliveira<br>
> <<a href="mailto:jdeolive@opengeo.org">jdeolive@opengeo.org</a>>wrote:<br>
><br>
>><br>
>><br>
>> On Tue, Jun 5, 2012 at 8:32 AM, Justin Deoliveira<br>
>> <<a href="mailto:jdeolive@opengeo.org">jdeolive@opengeo.org</a>>wrote:<br>
>><br>
>>> Hi Sebastian,<br>
>>><br>
>>> On Tue, Jun 5, 2012 at 1:03 AM, Sebastian Goerke<br>
>>> <<a href="mailto:goerke@lat-lon.de">goerke@lat-lon.de</a>>wrote:<br>
>>><br>
</div><div><div class="h5">> 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<br>
> and your patch seems to solve this issue.<br>
><br>
> Great.<br>
>>>><br>
><br>
> 2. issues with xlink schema references<br>
><br>
> Switching back to the old schema references will not help at this<br>
> point. Regarding the new OGC xlink policy, it is necessary to use<br>
> these new references from July on. We have to make them work with<br>
> the trunk scripts. Our test installation on<br>
><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>
><br>
>>>><br>
>>>> Ok... i am at a loss on this one. Can you provide any<br>
>>>> guidance on how you are making it work? From what I can tell<br>
>>>> this is not a geoserver issue. In the past I ran into this<br>
>>>> same issue and it had to do with xml.xsd (where xml:lang is<br>
>>>> defined) not being downloadable.<br>
>>>><br>
>>><br>
>>> Sorry... this was my misunderstanding (well really just more<br>
>>> forgetting) that the new xlink schema changes are in play<br>
>>> here... so does this mean we have to reference the new schemas<br>
>>> in order to property validate?<br>
>>><br>
>>>><br>
>>>> At the moment this is a blocker for me.<br>
>>>><br>
><br>
><br>
> 3. GetCapabilities tc9.2 and tc16.5<br>
><br>
> 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>
><br>
>>>><br>
>>>> Right, but what I am saying is that I don't think the fixes<br>
>>>> are valid. As far as I know the only delimiters for an http<br>
>>>> query string are "?" and "&". Is there somewhere you can<br>
>>>> point me in the http spec that says otherwise? So as I see it<br>
>>>> even putting version at the beginning of the query string<br>
>>>> still makes it impossible to parse it. In 9.2 the request:<br>
>>>><br>
>>>> version=1.1.0#request=GetCapabilities,service=WFS<br>
>>>><br>
>>>> I would think should be parsed into teh following key value<br>
>>>> pairs:<br>
>>>><br>
>>>> "version" : "1.1.0#request=GetCapabilities,service=WFS"<br>
>>>><br>
>>>> Again if I am missing something in the http spec I<br>
>>>> apologize.<br>
>>>><br>
>>>><br>
> 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>
> Cool.<br>
>>>><br>
>>>><br>
> 6. GetFeature tc44.1<br>
><br>
> We will have a further look for that and check your patch in, if<br>
> it seems to solve the problem.<br>
><br>
> Great.<br>
>>>><br>
><br>
> 7. LockFeature invalid-request<br>
><br>
> Ok, that was just fixed for r9 tag. I will fix it for trunk also.<br>
><br>
>>>><br>
>>>> Great.<br>
>>>><br>
>>>> Thanks again.<br>
>>>><br>
><br>
><br>
> Regards<br>
><br>
> Sebastian<br>
><br>
> Am 05.06.2012 05:14, schrieb Justin Deoliveira:<br>
>>>>>> HI all,<br>
>>>>>><br>
>>>>>> I have updated to the latest version of the wfs 1.1.0<br>
>>>>>> trunk tests. 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<br>
>>>>>> attached. 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<br>
>>>>>> recent commit that went in for this issue but I still<br>
>>>>>> don't think it is fixed yet. I generated a diff of the<br>
>>>>>> trunk against the r9 tag and attached the patch<br>
>>>>>> (xlink.patch). WIth this patch the tests are actually<br>
>>>>>> runnable for me.<br>
>>>>>><br>
>>>>>> 3. GetCapabilities tc9.2 and tc16.5<br>
>>>>>><br>
>>>>>> These tests use malformed URL's to test a service<br>
>>>>>> exception, but with the way they specify the version<br>
>>>>>> there is really no way to really parse it out and<br>
>>>>>> recognize. For instance:<br>
>>>>>><br>
>>>>>> <baseUrl>#request=GetCapabilities,service=WFS,version=1.1.0<br>
>>>>>><br>
>>>>>><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<br>
>>>>>> directly 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<br>
>>>>>> 1.1.0 response. Attached is a patch that changes the<br>
>>>>>> assertion to be more lax and not actually validate agains<br>
>>>>>> the ows 1.0 schema. Instead just checking the local name<br>
>>>>>> of the element.<br>
>>>>>><br>
>>>>>> 5. GetFeature tc23.4<br>
>>>>>><br>
>>>>>> Same fix as (4), no version specified but asserts the ows<br>
>>>>>> 1.0 exception schema. Patch attached.<br>
>>>>>><br>
>>>>>> 6. GetFeature tc44.1<br>
>>>>>><br>
>>>>>> Same as 5 and 6 but this assertion does tests against the<br>
>>>>>> exception code and the locator attributes. Fix doesn't<br>
>>>>>> validate against the ows 1.0 schema but still asserts the<br>
>>>>>> value of the exception code and locator.<br>
>>>>>><br>
>>>>>> 7. LockFeature invalid-request<br>
>>>>>><br>
>>>>>> The test uses the GET, which I think should be a post<br>
>>>>>> request. Patch attached.<br>
>>>>>><br>
>>>>>> Hope that all makes sense.<br>
>>>>>><br>
>>>>>> -Justin<br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>> _______________________________________________<br>
>>>>>> CITE-Forum mailing list<br>
>>>>>> <a href="mailto:CITE-Forum@lists.opengeospatial.org">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>
</div></div><div class="im">>>>> _______________________________________________ CITE-Forum<br>
>>>> mailing list <a href="mailto:CITE-Forum@lists.opengeospatial.org">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>
>>><br>
>>><br>
>>> -- Justin Deoliveira OpenGeo - <a href="http://opengeo.org" target="_blank">http://opengeo.org</a> Enterprise<br>
>>> support for open source geospatial.<br>
>>><br>
>>><br>
>><br>
>><br>
>> -- Justin Deoliveira OpenGeo - <a href="http://opengeo.org" target="_blank">http://opengeo.org</a> Enterprise<br>
>> support for open source geospatial.<br>
>><br>
>><br>
><br>
><br>
<br>
</div><div class="im">- --<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>
</div>iEYEARECAAYFAk/O+ZgACgkQq1hDh4aJykLY8QCeIog73rW07cX+PtYuLsSOcXJr<br>
HXEAniYqPolgyUZABhFN1wzD89zkGL8R<br>
=UN8Z<br>
-----END PGP SIGNATURE-----<br>
</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>