Oh dear! I just found out why I got a little confused. Section 8.1.1
only shows the header returned in the POST. Whereas the example in
section 12 (Atom Publishing Protocol Example)
shows the entry returned in body of the post to the media collection.
So I suppose things are working as I thought.
1. Posts to entry collections just return the header
2. Posts to media collections return an entry
Perhaps that could be made a little clearer in the spec.
Henry
On 9 Mar 2006, at 15:15, Henry Story wrote:
Oh! on closer look at the spec I see that I had misunderstood the
way entries get posted to the collection.
I thought an entry gets returned in the body of the POST when
posting to entry collections. I now see that the POSTing part to
both collections is identical. In each case one gets returned the
location of the document one sent. It is in the reading of the
collections that the difference shows up. Reading entry
collections, one gets a list of one's entries as first order
objects inside the feed; reading media collections one gets a feed
of entries that point to the resources one created. So in media
collections there is a level of indirection between the URI
returned and what appears in the feed returned at the href of the
collection.
I suppose it would make sense to return an entry when posting to
the media collection, since there is this indirection. This would
give the client a handle on the generated id, and other metadata.
Or perhaps one could just state that the id of that entry is the
url of the resource returned?
Henry
On 8 Mar 2006, at 20:50, Henry Story wrote:
So clearly this gives us a :Service, :Workspace, and :Collection
class. The relation between the :Collections of type :entry
and :media and the feeds they point to can be specified by the N3
rule
{ ?c a :Collection;
:href ?feedUrl;
:member-type :entry .
?feedUrl a atom:Feed;
atom:id ?feedId .
?feedId atom:update ?entry .
} => { ?entry atom:content [ a owl:unionOf ( atom:TextContent
atom:XHtmlContent ) ] } .
The above should say that for any collection of member-type entry
pointing to ?feedUrl with atom id ?feedId, all the entries on
feeds with that id will have contents of type text or xhtml.
I can see that the above is clearly wrong now.
Note: atom:update is the relation that a feed id has to all
entries that are part of feed documents with that id. In N3
{ ?feed a :Feed, :Version;
:id ?feedId;
:entry ?entry . } => { ?feedId :update ?entry } .
Anyway Here I am making 2 assumptions:
a1. that the linked list of feeds at ?feedUrl all have the same
id and that these are all the feeds with that id.
I suppose that is ok.
a2. that the content of those entries are limited to things of
mime type text/html, text/xhtml, text/plain.
that is wrong. And so is all the thinking below.
I wonder what people on this group think about assumption a1.
Thinking about it assumption a2 is very likely wrong. My guess is
that the difference between entry collections and media
collections is purely procedural, ie, how one interacts with them.
I suppose a test would be what your answer to the following
question would be: could it be that there is no syntactic way to
distinguish an entry collection and a media collection. For
example is it possible that someone could post some html to a
media collection?
POST /myblog/entry HTTP/1.1
Host: example.org
User-Agent: Thingio/1.0
Content-Type: text/html
Content-Length: nnnn
Title: Atom-Powered Robots run Amok
<html><body>Hello there</body></html>
Ok I suppose the entry created would then look something like this
<entry>
<title>Atom-Powered Robots run Amok</title>
<id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
<updated>2003-12-13T18:30:02Z</updated>
<content src="http://eg.com/xxx.html";>
</entry>
Worry 1:
The fact that posting to a media collection does not return an
entry, even though requesting the feed for the collection returns
a feed of entries, worries me a little. It means that if one
wanted to find the id for the posted object one would have to
scroll through the feed to find it. Is that asymetry really
necessary?
Well so that's probably enough for now. I have a couple of
questions, 2 assumptions and 1 worry.
Henry Story
[1] see presentation at http://bblfish.net/work/atom-owl/2006-03-02/
and ontology at http://bblfish.net/work/atom-owl/2005-10-23/
