Re: Why MD5 Headers are Imperative

>
>I am fully in compliance with every spec until I implement APP, so don't...
>

Here's how, remember you heard it here first:

http://example.com/resource;view=edit

-OR-

http://example.com/resource;id={xml:id}&view=edit

Either way brings up the writable representation (still, not necessarily a 
one-to-one relationship, even if it starts out as such) compliant with a 
majority of real-world clients, implemented in XHTML 1.1 using FormFaces to 
deploy XFORMS via Google's Web Toolkit (cross-platform AJAX compiler) using our 
Resin back-end.

This editor-on-demand utilizes PUT (and POST) properly on /resource with 
everything I've described enabled in terms of request/response headers.  I'm 
not breaking HTML by using PUT with forms that weren't designed for them, and 
I'm not subject to any AJAX drawbacks since XFORMS is asymmetrical anyway. 
Tab between code view and WYSIWYG, just like MSWORD '07s APP implementation.

Everything as I've described, implemented as a layer wrapped around my base 
functionality with absolutely no rethinking of its architecture or cache 
strategy required on my part, i.e. a fully standards compliant REST-based 
Atom Publishing System integrating legacy CMSs in PHP, Perl, Rails, Struts, 
Springs, Forks or Shocks.  ;)

Why would I need to support APP if it breaks a system which I can make work 
on a wider installed client base, which supports a wider variety of use cases?

-EJB