On 1/26/06, Sam Ruby <[EMAIL PROTECTED]> wrote: > 1) Servers can refuse to honor any request at any time for any reason. > The only requirements on such failures are listed in section 5.5.
Ouch, I hope we don't take this option. This actually makes writing a validator much harder and I presume it would also make writing a client much harder. Just looking at the accepted paces for -08 my job gets more difficult. For example, I have one test where I POST an Atom Entry to an entry collection with the wrong Content-Type: header. The acceptance of PaceRemoveMemberTypeMust kills that test since the entry collection MAY accept it now. How is a client supposed to detect that a server rejects any entry with a title/@type="xhtml"? I know that's probably going to be rare, but iti is currently allowed since there is currently no spec text which states: "A server MUST NOT reject a POSTed entry because of the choice of @type for any of it's Text Constructs." > 2) Extension elements in introspection documents may be used to express > policies or constraints. Clients are expected to ingore any such > elements that they don't understand, but must be prepared to accept the > consequences of downstream failures in such circumstances. +1 > These extensions will also likely fall out of the interop activities. > "Why was my request rejected?". "Because you didn't supply a valid > category name". "How should I know that?" "Oh, perhaps I should have > told you - here, now I put something in the introspection document that > you can use to dynamically adjust your GUI". +1 -joe -- Joe Gregorio http://bitworking.org
