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

[Mikel Maron]

Hi Jason, All,

You touch on a good points, so I'll responsd to the whole discussion here.
Travelling right now, so forgive the brevity (or praise the brevity with this list activity surge!)

> 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>

Perhaps not, but this was never the issue. Prior to georss.org, we already had the W3C Geo namespace for
describing a point. When we started to look at adding more geometries, the need for two flavors (I wouldn't
call them different standards, they're just different serializations of the same idea)  became very evident.
Take a look at the difference between a Polygon in Simple and GML.

> 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.

I've actually thought this was one objective of GML all along, and I'm really
starting to warm to the idea of finding a way to build up additional things into
the GML schema. 

Leave Simple alone .. it serves it's purpose very well, the gateway drug to 
heavy duty GIS. Combined with other RSS namespaces it's a very powerful
standard.

> 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.

Agreed. KML is good too. But I don't know how we started talking about
GeoRSS KML .. I don't really see how that benefits anything, just complicates
and confuses. 

It's being used as an example of the multiplicative work of supporting the GeoRSS 
standard. But that's pure FUD. Any sensibly coded parser only needs to support one
additional routine for each flavor, not 3 ..  the code to parse GeoRSS Simple is the
same across RSS1/2/Atom.

> 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.

Sounds sensible. I support keeping Simple as is, and focusing of key extensions
to the GML flavor, to keep everyone working together.

-Mikel





-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.eogeo.org/pipermail/georss/attachments/20070303/8fb87d9c/attachment.html