[CITE-Forum] more wfs 1.1 fixes

Justin Deoliveira jdeolive at opengeo.org
Wed Jun 6 12:28:58 EDT 2012


On Tue, Jun 5, 2012 at 11:33 PM, Sebastian Goerke <goerke at lat-lon.de> wrote:

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

I still have issues.

Caused by: java.lang.Exception: Can't find resource
xsd/ogc/ows/1.0.0/owsAll.xsd
at
com.occamlab.te.parsers.XMLValidatingParser.loadSchemaList(XMLValidatingParser.java:89)
at
com.occamlab.te.parsers.XMLValidatingParser.loadSchemaLists(XMLValidatingParser.java:110)
at
com.occamlab.te.parsers.XMLValidatingParser.<init>(XMLValidatingParser.java:166)
... 71 more


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:

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 {
http://teamengine.sourceforge.net/parsers}XMLValidatingParser.GMLSF1
org.xml.sax.SAXParseException: src-resolve: Cannot resolve the name
'ows:ServiceType' to a(n) 'type definition' component.
      Test wfs:readiness-tests Failed


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.


> 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-----
>



-- 
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/20120606/d5877c17/attachment.htm>


More information about the CITE-Forum mailing list