Greg Stein <gstein@xxxxxxxxxx> writes:
HTTP has a notion of a content type, and a content encoding. These are specified by the (wait for it...) Content-Type and Content-Encoding headers. Encodings are simply transformations that have been applied to the base content (one or more, and ordered).
It seems that your "mode" is akin to the C-E concept from HTTP. It seems advisable to run with the thought that way: there is an underlying content-type (a standard MIME type), and then you have a particular encoding for that content to enable its insertion into the Atom document.
This would allow feed sources to specify their original content as plain text, HTML, XML, or even a Word .doc file. And then there is another bit which says how you jammed that thing into the feed.
Greg has provided the context for my discussing why I think reproducing the efforts of HTTP or MIME in XML is a bad, very bad, idea for Atom to take on.
As the uses of mode and type have extended beyond just fixing the problem at hand, which was aimed at solving the silent data loss problem that RSS has, Atom is ending up being an envelope. I am consistent about some things and one of them is being averse to envelopes[1]. HTTP is perfectly suited to POSTing (NEWRESOURCEing ?) all media types and I believe handling of images, video, SVG, pdfs, etc. all need to take place without the requirement of an Atom envelope. Whether that is WebDAV, POST or NEWRESOURCE is a competely different thread.
Thanks, -joe
-- http://BitWorking.org http://WellFormedWeb.org