- From: Raj Singh <rsingh@opengeospatial.org>
- Date: Fri, 30 Sep 2011 14:22:27 -0400
- To: roBman@mob-labs.com
- Cc: "public-poiwg@w3.org" <public-poiwg@w3.org>
On Sep 30, at 12:35 AM, Rob Manson wrote: > Hey Raj, > >> No. I wanted to specify the author, but I'm having trouble figuring >> out how to represent it. See: >> http://rajsingh.org/poiwg/poi_logan_2.xml > > Yeah I think that's better. I'd assume if <value> is not defined then > the full content is assumed to be the payload? I suppose that's a possibility. It would look cleaner, but as a developer, I'd rather just always know to parse the <value> element as text, rather than have a conditional check to see if there are elements within <description>, and if not then treat <description> as text. >>> Is the <point><Point>...</Point></point> double nesting needed? >> >> Yes. Everything in <Point> is straight from GML 3.3. And the >> double-nesting will be useful. For one, it will avoid the problem with >> <description> above, where you don't want to mix CDATA with an >> element. I.e. it's easy to slip an <author> element in as a child of >> <point> without messing with the location specification in <Point>. > > Fair enough. I'd also like to be able to support the simpler geo:uri > too as a lot of developers would be happy with just that too. At the face-to-face we decided to put a stake in the ground here and have a single way to represent a point. There are too many "pet" point formats around. It would be better in the long run for the world to focus on a single one for interoperability. And what better place to have the canonical one than the W3C POI spec? And for practical reasons, if you're generating POIs, writing <Point><posList> instead of geo:uri is the least of your problems! And as a consumer of POI data (at least the XML format), it's nice to always know to find the coordinates in the <posList> element.
Received on Friday, 30 September 2011 18:23:04 UTC