All, I wanted to branch off the other thread as rather than discuss the merits of PaceCompoundEntries I want to see if the group feels there are implementation problems / limitations with the current treatment of media collections as described in draft 7. I have two questions
a) does the group feel that there is an implementation problem in draft 7. The gory details are below, copied over from the other posts. I have also attached a couple of suggestions from Joe on how to fix. b) does the group feel that there is a need to have editable meta data associated with entries in MEDIA collections, very interested in your thoughts, Rob Yates IMPLEMENTATION PROBLEM copied from "media posts and interop testing" post rob yates said: > I'd like to walk through the example in the specification (section > 12), which caused us a fair amount of confusion and use it to also > highlight some of our current problems. > > > 12. Atom Publishing Protocol Example > > > > This is an example of a client creating a new entry with an image. > > The client has an image to publish and an entry that includes an HTML > > "img" element that uses that image. In this scenario we consider a > > client that has IRIs of two collections, an entry collection and a > > media collection, both of which were discovered through an > > introspection document. The IRI of the entry collection is: > > > > http://example.net/blog/edit/ > > > > The IRI of the media collection is: > > > > http://example.net/binary/edit > > > > First the client creates a new image resource by POSTing the image to > > the IRI of the media collection. > > > > POST /binary/edit/ HTTP/1.1 > > Host: example.net > > User-Agent: Thingio/1.0 > > Content-Type: image/png > > Content-Length: nnnn > > Title: A picture of the beach > > > > ...binary data... > > > > The member resource is created and an HTTP status code of 201 is > > returned. > > > > HTTP/1.1 201 Created > > Date: Fri, 25 Mar 2005 17:17:11 GMT > > Content-Length: nnnn > > Content-Type: application/atom+xml > > Location: http://example.net/binary/edit/b/129.png > > I have edited what is in the current draft and removed the content > body as this is optional and is not returned by our server's > implementation. So now what is the client to do to get the readonly > url to use in it's next post. > > As far as we can make out the only option that it has is to retrieve > the media collection (potentially paging) until it finds an entry that > has this returned location as its "edit link". It can then pull the > content/@src to get the url to use for its post. This seems like a > lot of work to us and has forced us to go down an alternative route. > > > The client then POSTs the Atom Entry that refers to the newly created > > image resource. Note that the client takes the IRI > > http://example.net/binary/readonly/129.png and uses it in the 'img' > > element in the Entry content: > > > > POST /blog/edit/ HTTP/1.1 > > Host: example.net > > User-Agent: Thingio/1.0 > > Content-Type: application/atom+xml > > Content-Length: nnnn > > > > <?xml version="1.0" encoding="utf-8"?> > > <entry xmlns="http://www.w3.org/2005/Atom";> > > <title>What I did on my summer vacation</title> > > <link href="http://example.org/atom05"/> > > <id>urn:uuid:1225c695-ffb8-4ebb-aaaa-80da354efa6a</id> > > <updated>2005-09-02T10:30:00Z</updated> > > <summary>Beach!</summary> > > <content type="xhtml" xml:lang="en"> > > <div xmlns="http://www.w3.org/1999/xhtml";> > > <p>We went to the beach for summer vacation. > > Here is a picture of the waves rolling in: > > <img > > src="http://example.net/binary/readonly/129.png"; > > alt="A picture of the beach." > > /> > > </p> > > </div> > > </content> > > </entry> > > > Joe Gregorio Said: > Well, one option is to make returning the content body > a MUST level requirement. That would ensure the client > gets the info it needs. The other is to add some Link: headers > ala PaceUseLinkHeaders or PaceUseLinkHeaders2. > > HTTP/1.1 201 Created > Date: Fri, 25 Mar 2005 17:17:11 GMT > Content-Length: nnnn > Content-Type: application/atom+xml > Location: http://example.net/binary/edit/b/129.png > Link: <http://example.org/imagemetadata/129.atom>; rel="edit" > Link: <http://example.net/binary/images/129.png>; rel="external" > > Don't get caught up on the exact value of > the rel values, the *idea* is that the links you > need are returned via Link: headers in the response. > > Note also that there are two links, one points to the > URI of the resource to be used for public consumption "external", > and "edit" points to an Atom Entry created in a collection > that handles metadata for media entries. > - Show quoted text -
![http://example.net/binary/readonly/129.png"](http://example.net/binary/readonly/129.png"){kind=link}
