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

[Andrew Turner]

On 3/2/07, Pat Cappelaere <pat at cappelaere.com> wrote:
> Jason,
>
> We are talking about output formats here.
> So best practices so far are:
>  - Atom 1.0 + GML (limited)
>  - RSS 2.0 + GML (limited)
>
> So we let's call them:  Atom/GML and RSS/GML
>
> - Simple vs complex is becoming a minor issue. On the table would be to just
> have one that serves one community.  It is GML.

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.

I assume there are existing tools that already handle parsing/creating
full GML. Seems like having a "subset" of GML makes developers have to
modify their parsers to handle just the subset is work. However, just
being able to identify that this RSS/Atom item uses GML and then
pushing it off on the full GML parser is an easy thing.

Based on that idea, it seems like it would be useful for any
developers and the standard if open-libraries for parsing & creating
GeoRSS would go a long way in convincing any company to support the
standard. For example, GeoRSS4rb is a Ruby library for parsing all the
current incarnations of GeoRSS. I imagine there are similar ones
(maybe with some work) for PHP, Java, C++, Python, et al.

And for moving past a standard, Simple hasn't run out of life, it's
just getting going. Deprecating it now will more than likely scare
away the hundreds of users and interested parties that are just now
getting into it. Heck, Yahoo! only supports some odd modification of
GeoRSS, but at least they support something. Start expanding the
"Advanced" standard (supporting full GML) and provide easy tools for
devs to grab to add this support & *then* think about deprecating it.

Andrew