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
I think WFS Simple is a good idea, but I think it would be greatly improved by ditching XSD for RelaxNG. Hell, the “mass market” is hardly using schemas at all.
Now, for Atom/GeoRSS … why would anybody want to implement anything other than the Atom Publishing Protocol?
http://www.ietf.org/internet-drafts/draft-ietf-atompub-protocol-14.txt
Unless I’ve missed something big, the Atom Publishing Protocol doesn’t say anything about geographic or time-constrained queries. It’s pretty much focussed on document publishing use cases–getting individual entries, updating them, and posting new ones. Query doesn’t get much treatment at all. I’m surprised there isn’t even a common standard approach for category query in the RSS community. Am I missing something here?
Raj, read Joe Gregorio’s notes about OpenSearch.
http://bitworking.org/news/162/First-Atom-Publishing-Protocol-Interop-Notes
OpenSearch isn’t concerned with spatial queries, but the BBOX parameter is obviously the right thing to add.
Sounds not bad. “Geodata Query Service” is a nice name. But many questions remain to me: Currently query is deliberately limited and not mandatory. Is regex meant too? As you know regex slipped in almost by occasion (but to my happyness). What is the conclusion about BXFS and other encodings and schema languages? Error handling? What are the next steps to discuss (at the mailing list)?
@Sean: Why should WFS simple (or Geodata Query Service) be bound only to Atom/GeoRSS? and not to KML for example? There is quite a nice negotiation mechanism in WxS not existant to OpenSearch AFAIK).
Raj – Any chance of getting the https://mail.opengeospatial.org/mailman/listinfo/wfsbasic.users archives opened up to non-subscribers?
Sorry Allan no luck on opening the archives up to non-subscribers, but why not just join?