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

[Tim Bray <Tim.Bray@xxxxxxx>]

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