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

[Jason Birch]

Andrew Turner wrote:
> Let me be the first to cast in my vote of dissent on this. Simple has
> been embraced and is understandable by non-GIS professionals who want
> to map (let us call them 'Neogeographers'). It is the 'gateway drug'
> that gets them interested in the larger Geo-standards that they will
> grow into.

Hi Andrew :)

I really shouldn't have posted that note knowing that I wouldn't be able
to come back to it right away.  Sorry for stirring the pot then
disappearing.

I just don't feel that the differential between Simple and GML is enough
to justify having two active "standards".  Does anyone really have
difficulty with this:

<georss:where>
   <gml:Point>
     <gml:pos>45.256 -71.92</gml:pos>
   </gml:Point>
</georss:where>

instead of this:

<georss:point>45.256 -71.92</georss:point>

That's like saying that someone wouldn't be able to create a bold
italicized string because it involves nesting <strong><em>the
tags</em></strong>.  I don't think that you're giving neophyte users
enough credit.  Of course they'll prefer to use Simple (it's easier),
but I don't think that GML is hard enough to dissuade anyone.  Not even
a high-school birdwatcher (who would likely be using a WordPress plugin
anyway)

OK, let's look at this the other way...

If GeoRSS is resistant to supporting additional GML constructs beyond
what is currently in the specification, why does it bother with the GML
version at all?  You're adding complexity without the additional value
required to convince your users to "take a hit" of the arguably more
powerful drug.  At this point, even KML allows much more expression than
GeoRSS GML.

Not that swapping GML for KML is really an answer.  As much as I love
KML (mostly because of the compelling client software and the incredible
findability that Google brings to the table) I have no idea how it could
be successfully integrated into feeds without duplicating feed content
within the Placemark tags as name/snippet/description.

In general, it feels to me like GeoRSS has prevented a proliferation of
"standards" by saying that they're all OK and wrapping them in the
GeoRSS name (*). While this is successful from a marketing perspective,
and has brought all of the interested parties into a single room, I
don't think that it is a wise long-term strategy.  Especially if, now
that you have a level of simplicity that you're happy with, you're
willing to let people leave the room because they require more
expressiveness than the current specification supports.

I don't ever want to see GeoRSS become as open-ended as GML (that's just
way too complex for most people that are not developing data interchange
specifications) but it would be nice to have a single approved standard
on which to build approved extensions, leveraging existing standards
where possible.  What I see right now is the potential for the
possibilities to mushroom to the extent that no client software
developer will want to take the time to support all of them.

* I know that this is oversimplifying things and I'm sorry to trivialize
the important efforts of the folks who worked on GeoRSS just to make my
point...

Jason