[CITE-Forum] [CITE.SC] wfs 1.1.0 beta engine tests updated - Please review2010-09-30

Justin Deoliveira jdeolive at opengeo.org
Mon Oct 18 10:14:46 EDT 2010


Thanks for the reply Andreas. Some comments inline.

On Mon, Oct 18, 2010 at 12:41 AM, Andreas Schmitz <schmitz at lat-lon.de>wrote:

> Justin Deoliveira wrote:
>
> Hi,
>
> > > The OGC URN namespace identifier was approved a couple of years ago:
> > >
> > > <http://tools.ietf.org/html/rfc5165>
> > >
> > > Hmmm... when the original CITE work was done the "old" identifier was
> > required. Was there any sort of deprecation cycle? Or when the initial
> wfs
> > 1.1 cite tests were done was the spec not considered final and subject to
> > change? Apologies, i am not too familiar with the spec/cite
> > practices. Should perhaps the cite tests allow for both?
>
> I'm not sure about correct policies here, but I think this was discussed
> around half a year ago, and it was decided that we switch to the new,
> 'official' version in all of the tests, so all of the tests now expect
> the server to understand and use the new form. The test data has also
> been updated to use the official form now, so I suppose you'll have to
> switch to using the new form when running against later versions of the
> tests.
>
> You can still try to pass against the earlier versions of the scripts,
> but a lot of other fixes have been included in the newer versions, so I
> recommend using the new versions.
>

This is unfortunate news, for GeoServer at least. wfs 1.1 (or what
I thought was wfs 1.1)  has existed for over 2 years now. And since then
there have been many client applications built around it. We simply can't
start changing things like or we risk breaking clients. We require a major
version upgrade for that.

Do you have a reference to the discussions that took place to make this
change?

> > About the missing @srsDimension, it may have been omitted as redundant,
> > > since it's specified by the CRS. Note that if srsName is absent,
> > > srsDimension must also be absent:
> > >
> > > "When the srsName attribute is omitted, this attribute shall be
> omitted."
> > >
> > > <http://schemas.opengis.net/gml/3.1.1/base/geometryBasic0d1d.xsd>
> > >
> > >
> > > I don't quite understand. If the srsName is omitted this attribute
> should
> > be omitted... ok i understand that. But if the srsName is present is this
> > saying that this attribute is redundant because the dimension can be
> > inferred from the srsName? What is the point of it then in the schema?
>
> There are two things to consider here. The base GML 3.1.1
> schemas/schematrons/spec forces you to omit the srsDimension when
> omitting srsName. In case a srsName is present, you can also specify an
> srsDimension.
>
> The gmlsf profile that the tests use is a different story,
> unfortunately. The profile *restricts* the base GML schemas, with the
> intention of providing a more simple version of GML 3.1.1. Unfortunately
> this means that a sophisticated server which can output correct base GML
> 3.1.1 may well fail the tests. In this case, the gmlsf schemas simply do
> not include the srsDimension attribute, so any server which outputs GML
> using srsDimension attributes, will fail the tests. I'm not sure why the
> decision was made to use the gmlsf schemas instead of the base GML
> schemas, but it's the way it is.
>
> So in order to pass the tests, you'll have to make sure to output
> gmlsf-valid documents.
>

Seems strange to do this without a good reason. Seems like a bug in the
gmlsf profile to me.

>
> Best regards, Andreas
> --
> 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
>
> * * * * * * * * * * * * * * * * * * * * * * * * * * * *
>                    deegree day 2010
>             http://deegreeday.deegree.org
> * * * * * * * * * * * * * * * * * * * * * * * * * * * *
>
>


-- 
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/20101018/f3d98aa8/attachment-0001.htm>


More information about the CITE-Forum mailing list