2006/7/6, James M Snell:
<accept> identifies nothing more than the media-types that can be in the
HTTP post and put request. No specific server behavior is implied.
So if I POST an application/rdf+xml containing an RSS 1.0 item ("item"
element from the "http://purl.org/rss/1.0/"; namespace), the server
might "store" it and give me an Atom Entry Document whose atom:content
_contains_ the RSS 1.0 item; or "understand" it and give me an Atom
Entry Document whose atom:content is the content of the RSS 1.0 item
and metadata is extracted from the item also? and I have no mean to
know it?
(note that "understand" here is not the same "understand" as in Rob's message).
On thing that's in PaceUnifiedEntryEditing (and could be extracted and
"ported" to protocol-09) is to re-define app:accept so that it
identifies the media-types that can be in the HTTP POST and PUT
request *and* that the server will consider "content" of the created
entry.
That way, if I can, for example, POST an HTML form to the exact same
IRI as the "collection IRI" from the APP world, multipart/form-data
and application/x-www-form-urlencoded must not be listed (they are
accepted in POST requests, but not just "stored": one field is mapped
to the entry title, another to the entry summary, another to the entry
content, etc.)
That's a small difference, but it seems important to me. However, as
it's merely about other protocols and finally not directly related to
the APP (if I send an RSS 1.0 item and expect the server to
"understand" it to create the entry, I'm probably not an APP client),
I'd be OK for not having wording in the spec, but at least there
shouldn't be wording either that would prevent it (such as "if a
client sends an entity from a media type that is not listed, the
server must respond with an error status code"); that would be
overspecification.
Using "understands" in Rob's sense, I'd be OK that the spec does not
define a mean of telling the client whether the entity will be
"stored" or "understood" and leave it for an extension.
My 2 c€nts…
--
Thomas Broyer
