We had a nice group of about 15 at the OGC BOF at Where 2.0. Unfortunately, we were programmed at the same time as the OSGeo BOF, so a lot of the developers most active in lightweight OGC services like GeoRSS GML and WFS Simple (soon to be rechristened as GeoQuery Service as it moves towards 1.0, but more on that later) couldn’t be with us. Still, we were able to hit a couple GeoRSS issues and delve into other areas.

At one point we got into the issue of representing a single object that has different geographic locations at different times–like an airplane or a ship track. This was a big mailing list discussion earlier in the year, but I don’t think anyone mentioned the fact that Atom has an official way of handling this. If you look at the description of the <id> element in an <entry>, you’ll find this:

Two entries in a feed can have the same value for id if they represent the same entry at different points in time

So as long as <entry>s have the same id, you can change the time, geography, etc., and readers should consider them to represent the same object in different states. Sound like what we’ve been looking for?

On the WFS Simple/GeoQuery Service front, everyone seems happy with the basic data access proposal, but need more query support than time and bounding box. The general consensus from this group and various emails and site comments is to go with regex as a query language, but to NOT have XPath expressions. The thinking here is that XPath queries go too far towards requiring a certain level of XML representation of one’s data on the server, which is a much larger hurdle to adoption than simply outputting XML after a query has run in the database. A quick survey of the attendees felt that all the major databases out there had regex support, including Oracle, DB2, SQL Server, MySQL and PostgreSQL. Programming languages are all covered too.

You may be wondering, why yet another name change? We’ve already gone from WFS Basic (which was confusing because the WFS spec calls its HTTP GET profile WFS Basic) to WFS Simple. The reason is because there was a feeling at the last OGC Mass Market Working Group meeting that a service that did not require GML output should not be called WFS anything. This is a good point as the word Feature means something very specific in OGC terminology, and this service does not necessarily return features. I think it’s a “good thing” to not confuse the market by having a WFS service that doesn’t return GML, so barring something drastic–like someone has already used the term, WFS Simple is now GeoQuery Service.

So in upcoming weeks look for a new GeoQuery Service site on OGC Network with pages for Atom/GeoRSS queries (GQS-Atom?) and a “pure” RESTful approach to geodata query that Chris Holmes of GeoServer is cooking up.

In the OGC meetings last week WFS Simple was presented to the membership as a part of the “OWS4 GeoDSS Mass Market (formerly GeoRSS) IPR” (note this link will only work for OGC members for a few more days). It was approved as a discussion paper, which is a document that’s worth making public, but is not necessarily an “official” position of the OGC (as a Best Practices paper is).

There were two major areas of discussion at the meeting. One was around whether WFS Simple should harmonize with WFS and become the most basic WFS implementation. The other was related to Basic XML Feature Schema (BXFS) as the default output schema for WFS Simple. These are actually related items as the biggest problem with rolling WFS Simple into WFS would be the issue of having GML as a required output format.

Although at first blush it sounds nice to bring this work into an existing service, I agree with the opinions that it should stay separate. GML as a required output format is too important of a foundation of WFS to tinker with. Therefore I propose maintaining the separation and pursuing the following work items leading to a 1.0 specification.

1. keep WFS Simple focussed on being the generic geospatial data query language for mainstream web data formats like Atom+GeoRSS, KML, etc.

2. Componentize the design of the service, so that this is not really one service, but a simple, clear way to design services focussed on a particular data type like Atom+GeoRSS by adding or removing a parameter or two.

3. Re-emphasize the separation from WFS by moving towards a 1.0 specification with a new name, Geodata Query Service