My initial thoughts: - A definite incremental improvement on PaceMediaEntries and addresses my key concerns from the first time around.
- I'm -1 on the concept of supporting both [EMAIL PROTECTED] or enclosure link relations to point to the associated media resource. I think the media *is* the content referred to by the entry and worry that this opens the door for lots of ambiguity and/or abuse. For example, if a client can PUT full content to the entry after uploading the media; it then feels more like a hybrid entry that contains content + media + metadata, not just media + metadata. Specifically, I see the non-src forms of content as more than just metadata. If the WG feels the core needs to support the (non-src) content + media + metadata case (i.e. one entry refers to more than just a media resource, with associated metadata), then Thomas' objection regarding the lack of support for multiple media references seems more valid. Why only one if its really some full hybrid entry? If we want to support hybrid entries and/or multiple media resources for a single entry, let both be the domain of a well-defined extension that enables them, don't make them possible by leaving ambiguity in the semantics of the core that a client might be able to exercise. I don't think the current approach will benefit clients trying to write code that is portable across APP implementations. Note: that composition and hybrid content + media* entries would still be possible with the APP core, it just requires that the client does the composition to build an entry that is composed up using references to entries that refer to singular resources. This model would be guaranteed to work on *all* APP implementations, other extensions or vendor-specific approaches (like multipart) are just optimizations to get to this end result, but let's provide one clear, atomic mechanism that is guaranteed. - I'm OK with the notion that a collection w/out an app:accept elements means it is an entry-only collection. After all, the approach of this PACE fundamentally makes the store more entry-centric since all resources now have an entry representation. On the flip side, if we did match the http accept semantics, then we should probably match its syntax too (including qvalues and accept-extensions). I'm not convinced that we need that. - I'd still recommend we remove the <author> element from the response in the binary POST example. I think we all agree that its OK for the server to synthesize elements in the entry based upon contextual information (all entries in target collection might be authored by the same person, or author is implied by authentication context, etc) but I still think it is confusing given the posted data. Correspondingly, it might also be helpful to have the Title in the request actually impact the response. On 4/27/06, James M Snell <[EMAIL PROTECTED]> wrote: > > Ok, the first round of discussions around PaceMediaEntries was very > good. It's obvious given the various implementations out there and the > disagreements in that thread that more work is needed. Here's a second > attempt that incorporates some of the feedback from that discussion: > > http://www.intertwingly.net/wiki/pie/PaceMediaEntries2 > > - James > > == Abstract == > > Fix Media Collections by replacing it with an approach that works > seamlessly with existing podcasting applications. > > == Status == > > Proposed > > [snip] > > Section 7.1: Remove: > {{{ > "My Blog Entries" is an Entry collection and "Pictures" is a Media > collection. Entry and Media collections are discussed in Section 7.2.4. > }}} > > Section 7.2.2: Change: > {{{ > In an app:workspace element, the first app:collection element of each > type MUST refer to the preferred or primary collection. In the following > example, the "Entries" collection would be considered the preferred (or > primary) entries collection of the workspace and the "Photos" collection > would be considered the primary media collection: > }}} > > To > {{{ > In an app:workspace element, the first app:collection element MUST refer > to the preferred or primary collecton. In the following example, the > "Entries" collection would be considered the preferred collection" > }}} > > Remove the member-type element from the example in Section 7.2.2 > Remove the member-type element from Section 7.2.3 > Remove Section 7.2.4. > Remove Section 12 > > {{{ > 8. Collections > > 8.1 Creating resources with POST > > To add members to a collection, clients send POST requests to the > collection's URI. Collections MAY impose constraints on the media-types > of request entities POSTed to the collection and MAY generate a response > with a status code of 415 ("Unsupported Media Type"). On successful > creation, the response to the POST request MUST return a Location: > header with the URI of an Atom Entry Document representing the newly > created resource. > > If the server generates a response with a status code of 201 > ("Created"), the response SHOULD include an Atom Entry Document > representing the newly-created resource. Clients MUST NOT assume that an > Atom Entry returned is a full representation of the member resource and > SHOULD perform a GET on the member resource before editing. > > Clients MUST NOT assume that the URI provided by the Location: header > can be used to edit the created entry. > > 8.1.1 Example > > Below, the client sends a POST request containing an Atom Entry to the > URI of the Collection: > > POST /myblog/entries HTTP/1.1 > Host: example.org > User- Agent: Thingio/1.0 > Content- Type: application/atom+xml > Content- Length: nnn > > <?xml version="1.0" ?> > <entry xmlns="http://www.w3.org/2005/Atom";> > <title>Atom-Powered Robots Run Amok</title> > <id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id> > <updated>2003-12-13T18:30:02Z</updated> > <author><name>John Doe</name></author> > <content>Some text.</content> > </entry> > > The server signals a successful creation with a status code of 201. The > response includes a "Location" header indicating the URI of the Atom > Entry and a representation of that Entry in the body of the response. > > HTTP/1.1 201 Created > Date: Fri, 7 Oct 2005 17:17:11 GMT > Content- Length: nnn > Content- Type: application/atom+xml; charset="utf-8" > Location: http://example.org/edit/first-post.atom > > <?xml version="1.0"?> > <entry xmlns="http://www.w3.org/2005/Atom";> > <title>Atom-Powered Robots Run Amok</title> > <id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id> > <updated>2003-12-13T18:30:02Z</updated> > <author><name>John Doe</name></author> > <content>Some text.</content> > <link rel="edit" href="http://example.org/edit/first-post.atom"; /> > </entry> > > Note that the Entry created by the server may or may not exactly match > the Entry POSTed by the client. In particular, a server MAY change the > values of various elements in the Entry such as the atom:id, > atom:updated and atom:author values and MAY choose to remove or add > metadata elements. > > 8.2 The 'edit' Link > > Each member Entry within a collection SHOULD contain an atom:link > element with a link relation of "edit" that contains the IRI used to > retrieve, update or delete the member Entry. > > 8.3 Media Entries > > A Media Entry is an Atom Entry associated with a resource of any > media-type linked to the entry using either the atom:content element's > "src" attribute or an enclosure link relation. Media Entries SHOULD > contain an atom:link element with a link relation of "edit-resource" > that contains the IRI used to modify the linked resource. > > To add a Media Entry to a collection, clients send a POST request > containing a representation of the media resource to the collection's URI. > > Deletion of a Media Entry SHOULD result in the deletion of it's linked > media resource. Likewise, if a server allows clients to send DELETE > requests to the URI of the media resource, it's associated Media Entry > SHOULD also be deleted. > > 8.3.1 Title: Header > > A POST to a Collection requesting the creation of a Media Entry SHOULD > contain a Title: header indicating the client's suggested title for the > resource. > > POST /myblog/fotes HTTP/1.1 > Host: example.org > User- Agent: Thingio/1.0 > Content- Type: image/png > Content- Length: nnnn > Title: An Atom-Powered Robot > > ...binary data... > > The server MAY ignore the content of the Title: header or modify the > suggested title. > > Title = "Title" ":" [TEXT] > > The syntax of this header MUST conform to the augmented BNF grammar in > section 2.1 of the HTTP/1.1 specification [RFC2616]. The [TEXT] rule is > described in section 2.2 of the same document. Words of *TEXT MAY > contain characters from character sets other than [ISO88591] > [ISO-8859-1] only when encoded according to the rules of [RFC2047] > [RFC2047]. > > 8.3.2 Example > > Below, the client sends a POST request containing a PNG image resouce to > the URI of the Collection: > > POST /myblog/entries HTTP/1.1 > Host: example.org > User- Agent: Thingio/1.0 > Content- Type: image/png > Content- Length: nnn > Title: A picture of the beach > > {binary data} > > The server signals a successful creation with a status code of 201. The > response includes a "Location" header indicating the URI of the Atom > Entry and a representation of that Entry in the body of the response. > The Entry includes one atom:link with a link relation of "enclosure", > and a second with a link relation "edit-resource", respectively > identifying the IRI's used for public read-only referencing of the media > resource and the IRI to be used for modifying the media resource. > > HTTP/1.1 201 Created > Date: Fri, 7 Oct 2005 17:17:11 GMT > Content- Length: nnn > Content- Type: application/atom+xml; charset="utf-8" > Location: http://example.org/edit/first-post.atom > > <?xml version="1.0"?> > <entry xmlns="http://www.w3.org/2005/Atom";> > <title>A picture of the beach</title> > <id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id> > <updated>2003-12-13T18:30:02Z</updated> > <author><name>John Doe</name></author> > <content type="image/png" > src="http://example.org/media/img123.png"/> > <link rel="edit" href="http://example.org/edit/first-post.atom"; /> > <link rel="edit-resource" > href="http://example.org/edit/img123.png"; /> > </entry> > }}} > > Section 9: Change: > {{{ > Each entry in the Feed Document MUST have an atom:link element with a > relation of "edit" > }}} > > To > > {{{ > Each entry in the Feed Document SHOULD have an atom:link element with a > relation of "edit" > }}} > > Add Section 10.2 > {{{ > 10.2 The "edit-resource" Link Relation > > The Atom Protocol adds the value "edit-resource" to the Atom Registry of > Link Relations (see section 7.1 of [RFC4287]). The value of the href > attribute is an IRI that may be used to modify a media resource > associated with an entry. > }}} > > == Impacts == > > Actually makes things better > > == Notes == > > > ---- > > CategoryProposals > >
![http://example.org/media/img123.png"/](http://example.org/media/img123.png"/){kind=link}
![http://example.org/edit/img123.png"](http://example.org/edit/img123.png"){kind=link}