Thomas Broyer wrote:
What about rewording the above to "collections MAY impose
constraints on the formats that are created in a collection and MAY
generate a response with a status code of 415"? This uses the
generic term "format", following RFC 2616's explanation of status
code 415. Furthermore it omits the "Unsupported Media Type", since
it can be misleading.
I think the 422 status code added by WebDAV better suits the need.
http://www.webdav.org/specs/rfc2518.html#STATUS_422
How about "collections MAY impose constraints on the formats that are
created in a collection and MAY generate a response with a status
code of 415 (Unsupported Media Type) or 422 (Unprocessable Entity)"?
Sounds even better to me.
* Is the inconsistency between "application/atomserv+xml" and the
file extension of ".atomsrv" intentional? If not, could you please
bring those to in line since it's easy to forget about an 'e' or
insert one when it is not needed. (Personally I prefer "atomsrv"
over "atomserv" since the former is slightly shorter, but in the
end I don't mind, as long as it is handled consistently.)
How about using "svc" instead of "srv" or "serv"? "svc" looks more
like "service" than "srv" or "serv", which look more like "server",
which is not appropriate.
application/atomsvc+xml
I don't care much either way; both "srv" and "svc" are fine with me. But
it would be nice if the proposed file extension and the media type were
consistent.
Or maybe just application/atom-service+xml
I like it. But what file extension would you propose for it? .asvc (to
complement the four-letter .atom)?
Anyways, ought a Pace to be written to fix this inconsistency or can it
be handled informally by the editors?
* What about turning the <app:member-type> element into an
attribute, @type, on <app:collection>? At least in my understanding
<app:member-type> serves a purpose similar to the @type of Atom
Text and Content Constructs.
My position on this is to "refactor" Entry and Media collections…
Yes, let's see what atom-protocol comes up with. There is still time to
clean up the syntax afterwards.
Regards,
Andreas Sewe
