>>> Can a client modify an entry to contain a link relation element in the >>> following cases: >>> - To point to a resource on a different server entirely? >> >> There is no reason to believe that any of these resource are on >> the same machine to begin with. I could POST to media to machine A >> and have the MLE could be created on machine B and the editable media >> resource itself created on machine C. > > This requirement has to be stated explicitly, at least as a SHOULD. > This is the kind of thing that clients come to completely rely on, and > then you find some special-purpose server that decides this doesn't fit > in its model. "Well, the spec doesn't require me to accept link > relations which point to other servers." Finger-pointing rather than > interoperability.
I didn't quite understand your statement here. You make things more complicated than what Joe actually said. > > If that's completely unacceptable, the only alternative that would allow > good interoperability is to have an error code or feature advertisement > that allows the client to detect that the server won't allow this. A > generic "Forbidden" error (or other choice that could be made by the > server) is not enough to know what is disallowed and whether it is > always disallowed. "What did I do wrong?" the client plaintively asks. A generic error code would mean there was an error in the first place. Why is this the case? > >>> >>> Can a server ever ignore part of an edit and successfully process the >>> rest? >>> >> >> Yes. Think of a client that throws in a slew of random link elements with >> relations my server implementation doesn't understand. Same with foreign >> markup. The server is in charge. > > I completely disagree with this. It is way too unpredictable for > clients to deal with. Clients are left with the illusion of flexibility > -- it *seems* you can use Atom syntax extensions and do creative things > that other extended clients can understand -- but in fact the server can > alter this at will leaving the client without any control over what it's > really publishing. In many cases, the client won't even want the server > to store some stripped version of what it POSTed, because it can really > change the meaning of some entry to have the server strip some of the > content and markup. Imagine removing the start time and location when > I'm trying to publish an event entry to what I believe ought to be a > calendar feed. > > Some server changes to submitted documents is of course going to be > allowable (edit dates, server-provided IDs, changes which are > effectively XML canonicalization) but I believe these need to be > limited. The general case, which is how servers deal with unrecognized > elements, needs to be severely limited so that the server can either > reject the whole request or store as provided. This is a fundamental change to what has been said over and over on this mailing-list. Allowing the client to have more power than the current draft allows on the Atom member would mean we have to detail all those cases within the draft itself and would strongly limit its simplicity IMO. Besides, if you want to do fancy thing with a member, simply post a media resource which is an atom entry. This won't be modified by the server and will solely be treated a media resource. Then the client will have full control on it. The server must keep full control of the member resource. - Sylvain
