On 10/15/05, Tim Bray <[EMAIL PROTECTED]> wrote: > > Right, but someone still has to remember what I sent for > <atom:updated> last time... hold on; are you assuming that you're > always going to go get the entries collection before you do a PUT to > overwrite an entry, so then you'll know the atom:updated? I'm > beginning to be convinced. Either I remember both the URI to PUT to > and the last atom:updated, OR I look at the collection to fetch the > atom:updated. Then I'd want to explicitly document in the APP that > if I PUT an entry that's different but the <atom:updated> is the > same, that means I don't consider the difference significant in the > sense of http://www.atompub.org/2005/08/17/draft-ietf-atompub- > format-11.html#rfc.section.4.2.15
I thought there was pretty strong support on list that the client MUST do a GET on the member resource before editing. > Actually, there's a big issue here that we've never discussed. When > you POST/PUT an atom:entry in the APP context, it is plausible to > think that we could specify things in such a way that that atom:entry > is not in fact conformant to all the rules of atom-format; i.e. it's > an atom:entry but it's not an Atom Entry Document. Maybe surprising, > but not impossible. Agreed, this is a big issue that does need to be discussed. It may make parts of the protocol easier to implement if we don't require valid Entries on POSTing. One example is leaving off the atom:id means that the server can supply it while putting it in means that the client wishes to supply it. This arises if you are using the APP to migrate your weblog from one system to another and you are trying to be a good citizen and you don't want your atom:id's to change. On the other hand, if every Entry is valid it will make it easier to test the protocol at every stage by just running the bodies through the feed validator. -joe -- Joe Gregorio http://bitworking.org
