2005/12/1, Robert Sayre <[EMAIL PROTECTED]>: > > This pace conflates the media types of the server's representations > with the kinds of things it accepts,
It did, it no longer does since the 2005-11-14 edit (update for protocol-06). Or maybe you're talking about that sentence: The 'accept' attribute identifies the allowed content type(s) of the collection's member resources. Does "camera-ready" mean "to be accepted as-is, without any rewording"? > makes requirements that a server MUST accept POSTs of the correct > media type. If you think it should be a SHOULD, why not? How about something like "servers SHOULD NOT expose media types they don't accept and ofr which they will return a 415 Unsupported Media Type status code"? Or do you think the attribute should be optional? Absence of the attribute meaning "try and see" (different from accept="*/*") Or do you think it should just be a hint for clients to help users choose appropriate files? (and/or choose the appropriate collection based on what the user wishes to send) My mind is open, tell me what you'd like and if that's something I'm OK with, I'll make a PaceCollectionsAcceptedMediaTypes2. > Also, I'm not convinced this is useful in core. I don't think it is _required_ in the core. > I don't think metaWeblog.newMediaPost has had > problems this attribute would solve. -1. This attribute doesn't aim at "solving" anything, neither it is restricted "media" collections. When used on "entry" collections, it tells you that you can POST, say, an OpenDocument and have the server derive an Atom Entry Document from its content and metadata. Or the server (through the service description –or introspection– document) could tell you that you can POST an application/xhtml+xml;profile="http://www.microformats.org/wiki/hatom"; and it will derive the equivalent Atom Entry Document. The application/atom+xml media type could later be extended with a "profile" (à la application/xhtml+xml) or "type" parameter (à la multipart/*) to carry the kind of content used in an atom entry. For example, application/atom+xml;profile="http://www.microformats.org/wiki/hcalendar"; could then denote an Atom entry with atom:[EMAIL PROTECTED]"xhtml"] containing hCalendar. An Atom Protocol server could then inform the client that it accepts such special entries (and maybe process them in some special way, e.g. showing them in a "calendar" view). I've no problem with making it an extension, however I don't see any harm in having it (except the MUST, but we're here to discuss Paces and eventually make them evolve, so it can still be changed). -- Thomas Broyer
