Joe Gregorio wrote:
On 6/13/06, Bill de hÓra <[EMAIL PROTECTED]> wrote:
no partial entry handling**,
Are you really saying that you want every server to accept
every entry as-is and promise not to change anything or to
reject with an error?
No, I'm saying this part of the pace seems to allows vagueness, as
opposed to allowing innovative behaviour. I'm asking for fail-fast to
avoid scenarios like getting a 200 Ok where the posted entry was in fact
rejected (ie just like we get with forms validation errors in HTML
today). This pace allows that afaict.
In short I'm looking to constrain what can result in a 2xx.
That's completely unrealistic today and if you wanted to go
down this path it would make the APP
introspection completely unwieldly because we'd have to
have the ability to discover the list of acceptable authors,
the list of acceptable 'rel' values, the list of acceptable values
for atom:rights, the list of acceptable HTML markup in content
elements, the list of naughty words to avoid using in text, etc.
And don't forget that this would make the APP a 'must-understand'
protocol with respect to foreign markup.
I don't agree this makes anything mU. The server is going to do what
it's going to do, but it'll be constrained to sending pass/fail criteria
back to the client. If we really can have "mu" situtations, as in
neither yes or no is adequate for the server to send and it's not just
underspecification in the pace, then ok.
cheers
Bill
