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

Andreas Schmitz schmitz at lat-lon.de
Fri Oct 22 07:25:43 EDT 2010

Justin Deoliveira wrote:


> > > Issue 25 was the one that dealt with the URN identifier
> > >
> > http://portal.opengeospatial.org/?m=projects&a=view&project_id=85&tab=5&act=details&issue_id=285
> > > It was closed on 2010-07-10 21:52:46.
> > >
> > > A comment in the issue thread says that the specification only says to
> > > use a valid URN. Also the  RFC 5165 (Document that defines the OGC
> > > URN) was published in April 2008 and WFS 1.1.0 was published in  May
> > > 2005. So, I think the tests should allow any URN, or at least both URN
> > > syntaxes.
> >
> > allowing any urn in the tests would unfortunately mean a lot of changes
> > in the scripts again. I think it is consistent for the tests to use the
> > urn that is used in the testdata as well (which is how it is now).
> >
> >
> I definitely sympathize with how hard and how much work it is to update the
> cite tests. But then this means that servers that should be compliant
> according to the spec won't be able to get cite certified. It seems quite
> unfortunate for someone who has done the work to implement the spec
> correctly that the reason they cannot be certified is "it's too much work to
> update the tests properly".

I can definitely feel your pain (I've had my share of experience with
the various bugs and test assertions before we've been able to fix the

But regarding the urn issue, I think we've got to see how it relates to
the rest of the tests. One of the reasons why there is a test suite is
that it clarifies the specification where it's not entirely clear. The
spec left it open which urns to use (probably because the corresponding
RFC was not out yet). One could say that any WFS is therefore open to
use any urn it likes. One could also argue that the scripts and testdata
make use of a certain form of urns, and expect a WFS to be able to
import the data with these urns and expect the WFS to also be able to
output the data with these urns. The (optional) transaction tests
inserting new data are another thing. What urn to use when inserting?
Obviously a choice should be made here, and it's only logical that the
scripts should use whatever the OGC recommends (there is an OGC
recommendation document that mandates the use of the new form urns).

There are a lot of tests which I find a lot more
confusing/annoying. There is one test, for example, which expects a
service exception if the bounding box lies outside of the query crs. So
the scripts expect the WFS to behave in a certain way, which is not (to
my knowledge) specified at all. Another assumption that the tests
obviously make is that the coordinate systems in the test data are
actually supported by every WFS. Or the assumption that a WFS supports
non-ascii characters in feature type names.

The WFS scripts are full of such assumptions about how a WFS should
work, and even the basic tests are indeed very hard to pass. It took me
weeks to make the deegree WFS pass the tests, although it was in
production use for years already. But that's the way things are, the
scripts are there, and we cannot just rewrite large parts of them. Maybe
you can get out of it by using the older versions of the scripts (you
can choose a revision when running the scripts from the online engine),
as far as I know it is perfectly valid to use any published version of
the scripts to achieve compliance.

It's also not my place to decide how the scripts are developed. The
above opinions are just my personal opinions. I'm responsible to fix
bugs in the scripts as they come up, not to rework major parts. If it is
decided (usually by the CITE manager and/or the respective groups) to
make a functional change (eg. because a tests' assertion is faulty), I
can also implement it, as long as the work does not exceed certain
limits. But the group has to decide it first, so if you think the tests
do the wrong thing, maybe you should bring it up in the wfs group (the
wfs-dev list is probably a good place to start). And there's always the
practical impact of how many new bugs will be introduced when 21000
lines of XSL code are completely reworked.

Again, I can definitely feel your pain. I too think that achieving WFS
compliance should not be as hard as it is. Unfortunately I'm not making
the decisions here... Personally, I wouldn't have a problem with going
back to use the old form of the urns, but I feel that people will cry
out if we do that.

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.opengeospatial.org/pipermail/cite-forum/attachments/20101022/c5a05d3f/attachment.pgp>

More information about the CITE-Forum mailing list