I'm not subscribed to the APP mailing list, so hopefully this isn't
all redundant:
On 12/15/06, Lisa Dusseault <[EMAIL PROTECTED]> wrote:
A model where servers aren't required to keep such information
won't, in
practice, allow that kind of extension. If clients can't rely on their
markup getting stored, then clients can't extend Atom unilaterally
using XML
markup.
There are two different issues here, which I think has been
mentioned, but which might bear being clearly stated:
1) Do servers have to keep all extension data?
2) Can a server accept an entry while discarding some or all
extension data, or do they have to reject the entry and return an
error code?
I think the answer to the first question is clearly no--servers
shouldn't be required to store all arbitrary data that is sent to
them. So the questions are:
1) Which hurts more--data loss or rejected entries?
2) Is there any way to reduce that pain?
The pain of data loss is obvious--the data is lost. The pain of
rejected entries is having to fix and repost them or decide not to
try again.
In either case, it might be useful to be able to query the server
somehow to find out what it will and won't preserve. If data is
discarded, you can figure that out after the fact by loading the
resulting entry and checking whether the data is all there, but one
might prefer to know ahead of time if something is going to be lost
in order to be able to decide whether to post it or not. If the
entry is just going to be rejected, unless there's a way for the
server to communicate exactly which data it had issues with, fixing
the data to make it acceptable could be extremely difficult ("Hmm,
I'll leave this data out and try again...nope, still rejected. I'll
put that back in and leave this out...nope. I'll take both
out...nope. I'll put both back in and take yet another piece of data
out...").
So, how might a client query a server to see what it will preserve?
A few possibilities:
1) Have some way to request some sort of description of what will and
won't be preserved and what might be altered. I don't know how one
would go about responding to such an inquiry except to basically send
back a list of what will be preserved, including some way to say
"I'll preserve unknown attributes here", "I'll preserve unknown child
elements (and their children) here", "I'll store up to 32767 bytes
here", etc. If there is any known extension markup that a server
wants to explicitly state that it won't preserve, there may need to
be a way to do that too.
2) Have a way to do a "test post", where one posts the data one is
considering posting (or something structurally identical), but says
"don't store this--just tell me what you WOULD store". The response
could include what would be returned if one were to load the data
after it being stored, or it could be some sort of list of anything
that would be discarded or altered.
3) (I get the impression this could be done without requiring
changes--is this the sort of process that has already been
selected?) Post the data as a draft, reload it to see if it's all
still there. If so, or if what has been preserved is acceptable,
change it's status to "published" or whatever it's called. If not
delete it and give up or take whatever other action is appropriate.
My impression is that data loss would be less painful and more easily
dealt with than rejection of entries that won't be completely preserved.
...but I haven't followed the discussion, so what do I know.
