On 12/14/06, Lisa Dusseault <[EMAIL PROTECTED]> wrote:
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.
Older versions of the spec had this wording:
http://bitworking.org/projects/atom/draft-gregorio-09.html#rfc.section.4.3
"This RFC does not specify the form of the URIs that are used. The URI
space of each server is controlled, as defined by HTTP, by the server
alone. What this RFC does specify are the formats of the files that
are exchanged and the actions that can be performed on the URIs
embedded in those files."
Something along those lines could be added back in.
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.
This happens *all the time* in the real world. Many blog
comment systems have 'Preview' buttons. Why? Because you never
know how the server is going to handle your text.
Yes, it might be nice, in the future, to add a way for a server
to advertise its capabilities, but we do not have the real world
experience with the protocol to know what that should look like.
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.
I'm sorry but we've already argued this to death on the list and there
is nothing in HTTP which supports that view [1]. We've even reviewed
the scenario you are talking about and came to the opposite conclusion:
http://www.imc.org/atom-protocol/mail-archive/msg05415.html
This is the documented consensus of the WG. The next draft will have
verbage that makes this position clearer. If some implementations
find that too loose and want octet-for-octet storage they can use
always WebDAV.
[1] http://www.imc.org/atom-protocol/mail-archive/msg05415.html
Thanks,
-joe
--
Joe Gregorio http://bitworking.org
