A question on geowanking reminded me again of Bill de hÓra's enumeration of the keys to Atom's value:
- the extension rules (mustIgnore, foreign markup)
- the date construct rules
- the content encoding rules
- unordered elements
Even if you don't like Atom (or XML for that matter), if your carrier format is going to survive on the web, you need to have addressed these 7 primitives.
For the sake of carrying geographic information on the web, we'll need two additional primitives: location and location construct rules. An item or entry should have one location that is more or less analogous to atom:updated – the current location of the entry in a particular space (Which space? We'll get to that) – not ruling out the possibility of other semantically different locations. The Atom spec says that dates will abide by RFC 3339, period. This means one calendar system (read that as "spatial reference system"), period. Likewise, there should be a single dirt simple construct for location instead of competing options. Date and time can be represented elegantly as text strings with precision that increases as the string grows to the right, but geometries aren't so neatly captured and bulky blocks of XML or JSON seem unavoidable. Of all the geodata formats on the web, KML is doing the best job here: one coordinate system and a single simple yet powerful enough representations for geometries. KML is tied to the Earth, of course, for a Sun-centered (or other) system we'd need a different media type than vnd.google-earth.kml+xml.
KML also gets most of the other primitives right. KML's content encoding rules are an utter mess, but clearly the mass of free aerial and street view imagery is more than compensatory for most web developers. Your own mileage may vary.