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

[Jeff harrison]

Thank you

-----Original Message-----
From: "Peter Borissow"<peter.borissow at yahoo.com>
Sent: 03/02/07 2:53:45 PM
To: "Pat Cappelaere"<pat at cappelaere.com>, "Allan Doyle"<adoyle at eogeo.org>, "georss at lists.eogeo.org"<georss at lists.eogeo.org>
Cc: 
Subject: Re: [georss] WAS: GeoRSS Validation Service? RETURNING TO:multiplelocations and time

This might sound like a crazy idea but what if we sat down and wrote some code instead of debating whether or not clients will adopt a more expressive form of GeoRSS.

Parsing RSS and Atom is a joke. Parsing GML geometries is not that complicated either. In fact I wrote a limited GML parser that can handle points, lines, and polygons + their "multi-" varients in less than an hour. Adding the GeoRSS "simple" geometries took even less time.

Point is, perhaps it's time for some reference implementations - something developers can download and use/embed in thier software (at thier own risk/discretion of course). I actually envision at least 5 libraries, one for each of the following languages:

JavaScript (think Ajax)
Java (Using DOM or SAX - not XMLBeans or JAXB)
VB.NET
C#
C++


Any thoughts? 

Peter




----- Original Message ----
From: Pat Cappelaere <pat at cappelaere.com>
To: Allan Doyle <adoyle at eogeo.org>; georss at lists.eogeo.org
Sent: Friday, March 2, 2007 11:56:20 AM
Subject: Re: [georss] WAS: GeoRSS Validation Service? RETURNING TO: multiplelocations and time


Who are your customers?
Developers of Data Providers (IMHO)

For standards to be accepted, they have to be simple for a data provider
developer to implement on the server side and to build a client for.

We need more data providers out there.

We are going to have a hard sell to say:

Guys, you need to support:

1. GeoRSS/Atom 1.0 GML Simple
2. GeoRSS/Atom 1.0 GML Complex
3. GeoRSS/RSS 2.0 GML Simple
4. GeoRSS/RSS 2.0 GML Complex
5. GeoRSS/Atom 1.0 KML
6. GeoRSS/RSS 2.0 KML

As a client developer, I might not mind developing an interface for 2
classes of data and expand on the capabilities later (Simple->Complex) if I
want to support timespans, mulitple-geometries... GML parsing issue

Pat.


> From: Allan Doyle <adoyle at eogeo.org>
> Date: Fri, 2 Mar 2007 11:23:41 -0500
> To: <georss at lists.eogeo.org>
> Subject: Re: [georss] WAS: GeoRSS Validation Service? RETURNING TO:
> multiplelocations and time
> 
> 
> On Mar 2, 2007, at 10:51, Andrew Turner wrote:
> 
>> On 3/2/07, Pat Cappelaere <pat at cappelaere.com> wrote:
>>> 
>>> I really want to stay away from a simple and complex.  There is
>>> only one
>>> format with some best-practices.  I did not hear "let's deprecate
>>> simple"
>> 
>> Actually there was :
>> 
>>> Jason Birch Said:
>>> 
>>> 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)
>> 
>> Which is where my vote of dissent came from. I think GeoRSS is on a
>> great path and should continue to expand in areas that users are
>> requesting, or show "recipes" of how best to use GeoRSS with other
>> standards (Geonames, xCal, etc.). It's not time yet to start removing
>> things.
> 
> I agree!! Don't throw out Simple.
> 
> -- 
> Allan Doyle
> +1.781.433.2695
> adoyle at eogeo.org
> 
> 
> 
> _______________________________________________
> georss mailing list
> georss at lists.eogeo.org
> http://lists.eogeo.org/mailman/listinfo/georss


_______________________________________________
georss mailing list
georss at lists.eogeo.org
http://lists.eogeo.org/mailman/listinfo/georss


 
____________________________________________________________________________________
Looking for earth-friendly autos? 
Browse Top Cars by "Green Rating" at Yahoo! Autos' Green Center.
http://autos.yahoo.com/green_center/
_______________________________________________
georss mailing list
georss at lists.eogeo.org
http://lists.eogeo.org/mailman/listinfo/georss