Thanks for responding to my review. I look forward to seeing a
revised draft. Below I've excerpted the stuff that is still giving
me serious problems.
On Dec 7, 2006, at 8:36 AM, Joe Gregorio wrote:
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.
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.
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.
Lisa
