[georss] WAS: GeoRSS Validation Service? RETURNING TO: multiplelocations and time

[Jason Birch]

Raj wrote:
 
--------------
Even a company like Safe was balking at the limited functionality you 
see today.

--------------
 
Although I agree with your argument against complexity, I don't think that Dale's quote supports your reasoning to the extent that you took it.  Reading further, Safe's hesitation would appear to be from the fact that they had to support a matrix of nine different "formats" for GeoRSS, not because they had to support a small subset of GML.  My guess is that GML was a minor part of the puzzle for them compared to the general RSS, Atom, and web access which their product did not support at the time.
 
What I read into this is that with the acceptance GeoRSS has gained as a defacto standard, it would be well served to deprecate all but the following:
 
 - Atom 1.0 + GML (limited)
 - RSS 2.0 + GML (limited)
 
W3C is already recommended against, and I don't see a huge difference between Simple and the subset of GML in GeoRSS, and feel that Simple's continued existence just adds barriers for proper client-level support GeoRSS.
 
The GeoRSS brand of GML is not especially difficult to publish.  KML supports a broader set of geometry and time elements, and there are many users taking full advantage of both of these.  As long as you support a well-defined schema that publishers can read and understand, you won't have any problems in that area.
 
Supporting GML may be more difficult for client applications, but you're already imposing that burden, along with the extra work of having to support W3C and Simple.  By removing these formats from the mix, you give clients the ability to legitimately support only GML and give publishers the incentive to make the short hop to limited GML.  You also set a less complicated GeoRSS baseline, from which adding time and multi-geometries might not seem like so much extra work or complexity.
 
I understand that the current state of GeoRSS was needed to unify geo feeds, but now you are risking what you set out to prevent.  Latecomers that want to push the standard beyond the current definition are being resisted, increasing the likelihood of that competing implementations of the same functionality will emerge, leading to diminished interoperability.
 
As long as I'm stepping on toes (and getting into an argument that I'll probably end up losing)...
 
Why not consider deprecating the existing GeoRSS formats entirely, and moving to embedding KML in feeds as an alternative rather than as an enhancement?  This would give the publisher community a single geo:target while leveraging the significant support that KML has gained in the client space.  Ron's statement last week --indicating that GeoRSS in some ways has more in common with the KML than with GML -- and Carl's note today describing the problem domains of GML and KML both seem to support this approach.
 
Jason