+1 This new version addresses the concerns I previously raised.
I also think some examples of valid and invalid accept elements would be helpful. For example: <accept>image/*,*/xml</accept> Will accept image/png, and application/xml. Does not accept application/atom+xml. <accept>image/*,application/*+xml</accept> Invalid, '*+xml' is not allowed in RFC 2616 media ranges. <accept>entry,*/*</accept> Accepts any media type and atom entries. <accept>entry, */*</accept> Invalid, since there is a space after the comma. -joe On 4/30/06, James M Snell <[EMAIL PROTECTED]> wrote:
Ok, based on the input given for PaceMediaEntries2, here is PaceMediaEntries3. I think we're definitely getting very close. http://www.intertwingly.net/wiki/pie/PaceMediaEntries3 A number of incremental improvements. 1. Only specifies content/@src for the public reference URI. Still uses link/@rel=edit-resource to specify the edit URI. 2. Added "entry" value for app:accept, missing app:accept is equivalent to <app:accept>entry</app:accept>. <app:accept>image/*</app:accept> means ONLY image files can be posted. <app:accept>entry,image/*</app:accept> means that both entry documents and image files can be posted. 3. If provided, app:accept cannot be empty and must not contain leading or trailing whitespace. 4. Content-Location has been added to the examples to properly reflect the SHOULD requirement. 5. Cleaned out some of the old, no-longer relevant rationale from PaceMediaEntries. - James
-- Joe Gregorio http://bitworking.org
