Re: Why MD5 Headers are Imperative

None of these representations, in my implementation, exist as files -- only 
as cached output streams.  Regardless of use case, the concept is that there 
is one Atom Entry Document which does exist as a file (well, XML DB node) and 
serves as the source document for these output transformations. IMHO, this is 
a very 2006-relevant implementation particularly as server-side compilation 
and cacheing of output transformations is becoming more common, see XSLTC.

When architecting this system, I never intended for that representation to be 
a direct one-to-one relationship with the resource in order to preserve the 
flexibility of extending my basic unit of storage, the Atom Entry, internally 
without cluttering up output representations.  Nothing ever led me to believe 
that in order to interact with my system with a publishing protocol would 
require that I MUST establish a one-to-one relationship between my resource 
and my representation.  There is nothing in REST or WebArch which would ever 
lead me to deduce that I MUST conform to this requirement in order to achieve 
interoperability.  In fact, everything I've ever read has led me to, well, 
build my system exactly how I describe it -- _orthogonally_.

I am fully in compliance with every spec until I implement APP, so don't tell 
me that your spec breaks my compliance due to an error on my part because 
fixing compliance in such a case is as simple as disabling APP support, as it 
now stands.

-EJB

>
>All output representations, in HTML, XHTML, WAP, PDF or what-have-you, are 
>transformed using XSLTC in response to content negotiation.  So yes, we want 
>the Atom entry document to be as persistently cached as possible despite the 
>fact that no user of the system will ever receive an Atom representation of 
>the documents so managed.  Very real-world-today.
>