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

[Pat Cappelaere]

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.

So now we can focus on:  Atom/KML and RSS/KML

Users can specify the output they rather want to have from a WFS :)
Pat.




> From: Jason Birch <Jason.Birch at nanaimo.ca>
> Date: Thu, 1 Mar 2007 22:39:28 -0800
> To: <georss at lists.eogeo.org>
> Conversation: [georss] WAS: GeoRSS Validation Service? RETURNING TO:
> multiplelocations and time
> Subject: Re: [georss] WAS: GeoRSS Validation Service? RETURNING TO:
> multiplelocations and time
> 
> 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
> _______________________________________________
> georss mailing list
> georss at lists.eogeo.org
> http://lists.eogeo.org/mailman/listinfo/georss