Add proper support for UPDATESEQUENCE

I think we can trivially support this to pass the tests...

this isnt all that important at the moment...

This is fixed by the attached patches. Note: DOESN'T COVER WCS 1.1.0, ONLY WCS 1.0.0

Patch on 1.6.x is tested, patch on 1.7.x requires review.

Hi Saul,
I was looking around in the OGC docs and it seems to me that either what you're proposing is a custom extension, or else there are errors in the specs.
Here's what I found in the specs:

• the wfs 1.0, wfs 1.1, kvp request table does not mention the &updateSequence parameter at all
• the wfs 1.0 spec does not have it in the GetCapabilities xml schema, whilst the wfs 1.1 has it (it comes from OWS 1.0)
• both wcs 1.0 and wcs 1.1 specs do mention it instead in the kvp params table and in the xml schema instead

Yet none of the specs seems to mention what to do with the updateSequence param, when available.
Looking into the Web Service Common specification v 1.1, page 21, "7.3.4 updateSequence parameter" provides anyways the
behaviour you're talking about. Sigh, OGC specs are messy....
Soo... behaviour wise it seems ok, thought it's probably to be considered a custom extension for WFS 1.0 (since WFS 1.0 does
not reference any web services common spec and it does not mention it either).

Hum, the current implementation throws an exception when the updateSequence is equal to the current one, yet the web service common spec says that when they are equal the server response must be "service metadata document with only "version" and "updateSequence" parameters". I checked both the web services common specs (1.0 and 1.1) and both say the same... where is the exception coming from?

In the case of WFS 1.1 to provide such an empty response one would have to include the filter capabilities anyways since they are not optional in the schema. (I'm going to write to wfs-dev about this, looks like a mistake to me). In the WFS 1.0 case it's even worse none of the capabilities element is optional, and you have to report at least one feature type, so I guess this defeats at least partially the purpose of your patch.

In WCS land the situation is similar, 1.0 does not allow main elements to be null, whilst wcs 1.1 is probably the only one that allows you to follow the common web services spec and return just an emtpy <Capabilities> element.

In WMS 1.1 according to the DTD you have to provide the Service and Capability elements as well, so it's similar to the wfs 1.0 situation.

Ok, got it. The exception comes from the WMS 1.1.1 specification, that states if the request update sequence is equal, the response should be "Exception: code=CurrentUpdateSequence".

Yet, for all of the other protocols the situation is different. WFS 1.1 is referring to OWS 1.0 so I guess the common web services spec 1.0 applies, WCS 1.1.1 referers to the ows 1.1.0 spec, whilst all of the others are not referring to any of the common web specs that I can see, nor mention how to use the udpateSequence param... what a mess???

Ok, I talked with aaime about this, and here's the result: there are two "styles" of updateSequence support.

A) "ad-hoc" updatesequence support. WMS 1.1.1 and WCS 1.0.0 both provide a standalone description of updatesequence that is almost exactly the same between the two. Read the specs (WCS page 11-12, for example) to see this bit. It's easy to implement and easy to understand.

B) "OWS 1.1" updatesequence support. There's an ogc "base standard" called OWS Common. It's a set of base schemas providing common base definitions of getcapabilities, capabilities responses, operation extensibility, etc. This common "base standard" includes a description and specification of how updatesequence is supposed to work in all services based on top of OWS common 1.1 or higher. Currently that is only WCS 1.1.1 (not yet released).

For now we will provide an implementation of A, but not B. Note, there is no support for updateSequence in the WFS 1.0 or 1.1 specifications. Read them and search for the words "updateSequence" and you'll see a partially-formed definition in one or two places, but nothing that's concrete enough to get implemented.

Resolution: WCS 1.0.0 and WMS 1.1.1 will have updatesequence support implemented using the "ad-hoc" procedure defined in those standards, and that implementation is included in the attached patches.

WFS 1.1, WFS 1.0 and WCS 1.1.0 will not include updateSequence support. In the future, if we implement services based on OWS common 1.1+, we'll revisit the updatesequence question for those specifications.

Hi Saul, 1.6.0 is out so if you want to merge the patches into 1.6.x that's the best time (we'll make another release in a couple of weeks)

Resolved as of revision 8406

Integrated in geoserver-1.6.x #49 (See http://gridlock.openplans.org:8080/hudson/job/geoserver-1.6.x/49/)

You want to open a new jira for 1.7.x? So that this gets tracked on there. You said that it needs review, it'd be good to have it there with the patch and the request for review.

Chris: patch is already comitted on trunk. Somehow I forgot to mark that on this JIRA issue. I'll update this JIRA right now.

Ok, awesome. May have been before our hudson was hooked up with comments - now you just need to include the issue number in the commit message and it'll make a comment here when it builds successfully with it.

All these issues have been in "resolved" state for at least one month (many of them, much more than that). Since no one has reopened them, I'm mass-switching them to closed state. Reopen if you feel the issue has not been addressed properly.