[georss] GeoAtom (split from Re: GeoRSS Location References)

[Sean Gillies]

Andrew Turner @ mapufacture wrote:
> On Tue, Apr 1, 2008 at 12:46 PM, Raj Singh <raj at rajsingh.org> wrote:
>> On Apr 1, 2008, at 12:41 PM, Sean Gillies wrote:
>>  > Wait, are multiple entry locations making a comeback?
>>
>>  No! Andrew, let me re-write your example. I thought we were agreeing
>>  to this:
> 
> Mikel locked me in a car on a road trip and preliminarily convinced me
> that Multiple entries is better. There are all the reasons that Sean,
> Mikel, Josh all point out: works with existing, semantic, etc.
> 
> However, the one that won me over was the fact that Atom entry already
> supports (or can be expanded to support) many more rich attributes:
> categories, time, authors... Simply, a story can have multiple
> locations that happened at different "times". If we wanted to carry
> georss:collection forward to handle this, we would get into a huge
> quagmire of extending geo* to do all sorts of non-geo things: time,
> categories, tags, et al.
> 
> Instead, go back to the tenant that we should just be adding Geo to
> existing formats/practices rather than bringing them into Geo.  or
> something like that.
> 
> Of course, I will follow-up by saying that I think multiple entries to
> handle multiple geometries would also suggest that batch RESTful
> operations are a good idea. While it's nice to be able to edit any
> single geometry, I shouldn't have to hit the server 4 times just to
> post 1 story with 3 locations. Or by editing that entry to remove a
> location and add 2 would mean making 4 calls (PUT entry, DELETE
> location, POST 2 locations).
> 
> What seems better is to PUT the multiple entries - and if there is any
> failure, then the entire request fails (transactional) with
> appropriate error responses for why it failed (bad geometry or title
> in one of the geometry-entries perhaps).
> 
>>  <entry>
>>     <link href="http://example.org/entries/1"/>
>>     <title>Cedarburg Trip</title>
>>     <summary>We went to visit
>>        <span id="downtown">downtown Cedarburg</span>
>>
>>        before the conference. Had some great sandwiches at Joe's.
>>        If you haven't been to Cedarburg, Wisconsin, then you haven't
>>        really experienced the MidWest...
>>     </summary>
>>     <georss:where id="downtown">
>>        <georss:point>...</georss:point>
>>     </georss:where>
>>   </entry>
> 
> I admit that this I liked this idea originally. Very succinct.
> However, there are several problems. First is that you probably would
> have the summary wrapped in a CDATA, since it isn't really part of the
> Atom XML. This would preclude id bashing, but also it's only a fake or
> tenuous link from the georss:where id to the span id in the summary.
> It would be just as meaningful to point to a binary address in an
> image file.
> 
>>  (2 identical IDs are probably a bad idea, so a different ID or
>>  attribute should be used)
>>
> 
> I suggest putting up your suggestions and basic thoughts on the GeoRSS
> Proposals for Multiple Entries, Location Reference so we can start
> collating for a poll.
> 

Andrew,

I think we can leave the publishing protocol issues out of it, or try to
solve them within other communities (AtomPub, OpenSocial, etc). I did
show you John Panzer's proposal, yes?

Does the georss.org site have a wiki? If not, could we start up a wiki
for the ground state effort?

Sean