Monday, January 30, 2006, 2:16:58 PM, Joe Gregorio wrote:
>> We don't say anything about the effects of atom:id in a posted entry. >> I expect that some client implementors will be surprised when >> implementations change the atom:id, as some servers will; especially >> when this is obviously in violation of the atom syntax id rules. > I don't think this behaviour is in any way "obviously in violation" > of the atom syntax rules since criticising these justifications: > the server had no way of determining if the incoming atom:id is > universally unique to begin with Why would the server assume that the client is sending illegal Atom (with non-unique ids), any more than it would assume that the client is sending a GET request when it really means DELETE. It is unambiguous whether the id is intended to be universally unique. If two entry representations have the same id then they represent the same entry, if they don't then they don't. The server shouldn't be ignoring valid requests from the client, and guessing what they might mean assuming that they are wrong. > nor does it know the 'intent' of the author, which may be that a new > atom:id should be generated: If the protocol doesn't provide enough context for the server to know the intent of the author, then I think we are missing some constraints. Re: http://www.imc.org/atom-protocol/mail-archive/msg04334.html Have I got this right: entries exist before they are posted to the server, and posting an entry to the server merely creates a document on the server to hold the entry representation? If the semantics of POST are to create a document resource to represent the entry that has been POSTed, then I would assume that it would be the entry represented in the POST body that would be represented in the document. Not a completely different entry that the server has just made up (different because it has a different id) that happens to look similar. If POST really is intended to mean "create a resource, any resource", then yes, the server can create a document with a different id, because it isn't the same document. The spec should be littered with MAYs though to warn of this unusual behaviour. This strikes me as being incredibly weasily, basically any software can ignore the requirements of atom:id permanance by saying, no it hasn't changed the id of the entry, it has created a clone of the entry which therefore must have a different id. I don't think that this is at all in the spirit of the Atom Syntax id rules. -- Dave
