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

[creed at opengeospatial.org]

I am on travel but this dialogue triggered a memory about a discussion I
had with Tim Bray sevral years ago regarding geo and Atom. When I get
back, I will check my archives and send the group these emails.

Carl


> 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.
> _______________________________________________
> georss mailing list
> georss at lists.eogeo.org
> http://lists.eogeo.org/mailman/listinfo/georss
>