I have a question please. In the second example where you created a png image on the server the server responded with:
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"; /> <link rel="enclosure" href="http://example.org/media/img123.png"; /> <link rel="edit-enclosure" href="http://example.org/edit/img123.png"; /> </entry> What does the location "http://example.org/edit/first-post.atom"; now refer to? If I'm assuming correctly it should refer to an Atom Entry containing the metadata for the created media resource. Is this true or false? Thank you, Sammy "James M Snell" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > Alrighty folks, it's been several weeks. Several implementations are > out there being tested. We've talked about it, hashed it over, etc. > Media collections are broken. Here's a fresh attempt at fixing them. > > http://www.intertwingly.net/wiki/pie/PaceMediaEntries > > #pragma section-numbers off > > == Abstract == > > Fix Media Collections by replacing it with an approach that works > seamlessly with existing podcasting applications. > > == Status == > > Proposed > > == Rationale == > > The WG seems to be in agreement that the current definition of Media > Collections is horribly broken. There is inconsistency in the behaviors > of media and entry collections, there is ambiguity in what the Location > header needs to point at, there are problems when trying to match up > what a client posted to what actually shows up in the collections Atom > feed, etc. This Pace attempts to fix all of those issues by redefining > the problem. > > In the syndication space, there is a pre-existing notion of entries with > enclosures. Podcasting, photocasting, etc all use the enclosure link to > associate media resources with entries. Atom defines an enclosure link > relation for that very purpose. There is no reason why we cannot > leverage that same link here. Rather than having a "Media Collection", > in which member resources are any arbitrary media type, we have a > collection of media entries, in which each member is an Atom entry with > an associated enclosure link. A new "edit-enclosure" link relation is > introduced to provide a clean separation between the IRI used for public > referencing of the enclosure and the editable representation of the > resource. > > The key advantage of this approach is that it works seamlessly with > existing *casting style applications. It also resolves all of the > issues that have been raised in relation to media collections. > > == Proposal == > > 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 includes a body in the response, the > entity MUST be an Atom Entry Document representing the newly-created > resource, equivalent to that which would appear in the collection's feed > document. > > 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.2 Media Entries > > A Media Entry is an Atom Entry that is associated with a resource of > any media-type. Media Entries MUST have at least one atom:link element > with a link relation of "enclosure" that contains the IRI used to > retrieve a representation of the associated media resource. Media > Entries MAY contain an atom:link element with a link relation of > "edit-enclosure" that contains the IRI used to retrieve, edit or delete > a modifiable representation of the media 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. > > 8.2.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.2.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 > > {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-enclosure", 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>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"; /> > <link rel="enclosure" > href="http://example.org/media/img123.png"; /> > <link rel="edit-enclosure" > 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-enclosure" Link Relation > > The Atom Protocol adds the value "edit-enclosure" to the Atom Registry > of Link Relations (see section 7.1 of [RFC4287]). In an Media Entry, the > value of the href attribute is an IRI that may be used to retrieve, > update and delete a media resource associated with the 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}