W3C home > Mailing lists > Public > public-poiwg@w3.org > September 2011

Re: POI data model examples serialised as JSON, XML, HTML5 & KML

From: Rob Manson <roBman@mob-labs.com>
Date: Fri, 23 Sep 2011 03:15:38 +1000
To: "public-poiwg@w3.org" <public-poiwg@w3.org>
Message-ID: <1316711739.24801.51553.camel@robslapu>
Hey Raj,

> First of all, kudos for stepping forward with examples. Very brave! 

it's just the rough output of me trying to think through all the details
we discussed and I'm very happy to receive constructive criticism...like
yours below 8)

> - can you put it on the wiki so we can all edit?

Yeah...will do.  Just wanted to get a first round of feedback first and
didn't want to interfere with the examples I think matt is going to put
up from Boulder.  But short answer is yes...definitely.

> - this whole idea of pointing to alternate versions of the same thing
> is starting to worry me. This is functionality that seems better
> suited to a service interface/negotiation and not something that
> should be encoded in the file.

Do you mean the serialisation type?  e.g. xml or json, etc.

This is definitely one of the key points I'd like to discuss further.  I
think you're absolutely right about content-type negotiation.  HTTP
Headers, User Agents and Servers are best at handling that.

I probably erred too much on the side of being explicit here.

> - you have different IDs in each format. Shouldn't the ID be the same
> and the href change? So the POI is should be
> http://mob-labs.com/poiwg/example01/pois/123 and the href for the XML
> encoding would be http://mob-labs.com/poiwg/example01/pois/123.xml,
> and the href for JSON would be
> http://mob-labs.com/poiwg/example01/pois/123.json, etc.

Yeah...I think that's a great point and relates directly to the point
above.  Also see the note I put in there about Atom requiring that an id
is a permalink/URI and not just a relative id.

> - you have a lot of Atom elements at the POIS object level that we
> haven't discussed. I like it but not sure that's the group consensus

Yeah...I thought some of them might be a bit contentious 8)

I started with the UML data model diagram you did...but when I got to
things like "label" it didn't seem to map cleanly to the existing
conventions in Atom, Dublin Core or KML.  So I just followed each of
these points through to try to pull out the key metadata fields that are
common across all these different specs.  Where they weren't completely
common I went with the most popular one e.g. author vs creator.

In this vein I'd also like to discuss atom:category and link rel=tag in
more detail too.

But my goal with this is really just to stir up a bit more discussion at
this detail level based on the existing specs and very happy to learn
more about what's already been agreed by the broader group.

In this I also promoted a lot of these up out of a metadata block into
the top level...but happy to discuss this further too.

> - JSON: the POI object has gone away. So you just have the array POIS.
> I see what you're doing and that this array-style format doesn't need
> the POI object, but it doesn't "feel right" to me.

Well...each of the {...} objects inside the pois array is really a poi
object.  I did have a {type:poi} key in there initially but it seemed a
bit redundant.  Happy to add that back in if people think this is
useful...but I think having any type other than "poi" inside a pois
array would be a bit strange 8)

Received on Thursday, 22 September 2011 17:16:07 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:05:22 UTC