RE: Hierarchy - Part 2 - How we think our data would look in ATOM

[Yaron Goland <yarong@xxxxxxxxxxxxx>]

It's funny you mention address book and mobile contacts. About a month or two ago we actually had an internal discussion with a team that was confused about why we weren't using ATOM where this very example came up (e.g. synching filtered address book info to a mobile phone) and I said "and for that you should use ATOM!"

We actually have more deeply nested data than you might think but nevertheless the majority of the data (if I were to make a blind guess) typically consists of relatively flat records with lots of properties that like to link to each other. And that does sound familiar.

The PUT semantics in ATOM still scare me way too much. I suspect any ATOM server I'm involved with will probably ban using PUT with application/atom+xml. I would probably require that we either use something like application/atomMerge+xml (which I just made up) and then either use that with PUT or PATCH. I have heard mention that some folks in ATOM land are thinking about merge based semantics. Are there drafts anywhere? I tried looking for them but didn't find anything.

There a bunch of extensions I suspect we'll need but I presume we can bring those to the list to discuss? For example, in draft-nottingham-atompub-feed-history paging is done by first/last/previous/next. But what we would really want is skip+show. E.g. a paging request of the form "skip the first X entries and show the next Y". But those are just details. We need to collect all the details together and bring them to the list for discussion.

        Yaron

P.S. "That's not an argument!"

> -----Original Message-----
> From: Tim.Bray@xxxxxxx [mailto:Tim.Bray@xxxxxxx]
> Sent: Wednesday, June 20, 2007 9:05 PM
> To: Yaron Goland
> Cc: atom-protocol@xxxxxxx
> Subject: Re: Hierarchy - Part 2 - How we think our data would look in
> ATOM
>
> On Jun 20, 2007, at 5:20 PM, Yaron Goland wrote:
>
> > What I have tried to do in this e-mail is take an existing Web3S
> > example data structure and translate it into ATOM.
>
> Ouch, that looks like a lot of work.  Look, you've chosen a data
> model that's deeply un-"publication" like.  Presumably your reasons
> for doing this are good.  I have not heard any voices saying "The
> Live team should be required to use APP for updating their address
> book".  All the angst arose because of the initial statements along
> the lines of "APP is flawed in the general case and can't do
> concurrent updates and can't handle non-atom-entry data objects so
> we're going to have to invent a new protocol."  Phrased that way, it
> sounded like you were trying to invent a new general-purpose update-
> web-content data model, and that would be controversial.
>
> The world has relatively few deeply-nested hierarchical data objects
> with half-a-billion leaves.  It's unsurprising that you need some
> special techniques to manage yours.  There are people out there who
> will whine if what you choose isn't RESTful, but the universe of
> RESTful protocols is bigger than APP.
>
> I suppose it's possible that if APP client & server implementations
> become as ubiquitous as seems likely, you might come under pressure
> to build a bridge.  Might it be reasonable to consider offering a
> user a view of their own (relatively small and flat) contact list as
> an Atom publication, so an APP-client-equipped cellphone could manage
> the online contacts?  I dunno, maybe.
>
> Remember the Monty Python sketch?  "No, this isn't the room for an
> argument."  -Tim