2006/5/16, Robert Yates <[EMAIL PROTECTED]>:
So I have been running some thought experiments http://robubu.com/?p=6 on using the Atom Publishing Protocol with PaceMediaEntries4 for calendaring. One of the interesting things about calendaring is that there are potentially at least 3 different representations of the same event data, i.e. iCalendar, xCalendar and rdfCal. The theoretical calendaring server would accepts posts of any of these types and subsequently make available all three representations of the data. The clients can then choose the representation that they wish to work with. With the current PaceMediaEntires4 the response to a POST to create a new Calendar event (in any format) would look like this. 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" Content- Location: http://example.org/calendar/1.atom Location: http://example.org/calendar/1.atom <?xml version="1.0"?> <entry xmlns="http://www.w3.org/2005/Atom";> <title>Annual Employee Review</title> <id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id> <updated>2003-12-13T18:30:02Z</updated> <author><name>John Doe</name></author> <summary type="text" /> <content src="http://example.org/calendar/1"/> <link rel="edit" type="application/atom+xml" href="http://example.org/calendar/1.atom"; /> <link rel="edit-media" type="application/calendar+xml" href="http://example.org/calendar/1"; /> <link rel="edit-media" type="text/calendar" href="http://example.org/calendar/1"; /> <link rel="edit-media" type="application/rdf+xml" href="http://example.org/calendar/1"; /> </entry> What I don't like about this is that I can only have one content/@src and so I am forced into using content negotiation to get the different representations of the content.
You can only have one content/@src but you can have [EMAIL PROTECTED]"alternate"]. As, for the moment at least, you only publish events that have been created via AtomPub HTTP POST, you then have a "source representation", from which you derive the other two. So you should be able to produce a content/@src with the media type of the "source representation" and two rel="alternate" links for the other two, along with rel="edit-media" links for each three representations of the resource: xCal/xCalendar, iCalendar and rdfCal (I still think it should be rel="edit" as the Atom Entry Document is also a representation of the very same resource but, well, rel="edit-media" works so I'll use it here) So, given the example from your blog: POST /calendar HTTP/1.1 Host: example.org User- Agent: Thingio/1.0 Content- Type: application/calendar+xml Content- Length: nnn <?xml version="1.0" encoding="UTF-8"?> <vcalendar version="2.0" prodid="-//hacksw/handcal//NONSGML 1.0//EN"> <vevent> <uid>[EMAIL PROTECTED]</uid> <dtstamp>19970901T130000Z</dtstamp> <dtstart>19970903T163000Z</dtstart> <dtend>19970903T190000Z</dtend> <summary>Annual Employee Review</summary> <class>PRIVATE</class> <categories> <item>Business</item> <item>Human Resources</item> </categories> </vevent> </vcalendar> the server response could be something like: 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" Content- Location: http://example.org/calendar/1.atom Location: http://example.org/calendar/1.atom <?xml version="1.0"?> <entry xmlns="http://www.w3.org/2005/Atom";> <title>Annual Employee Review</title> <id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id> <updated>2003-12-13T18:30:02Z</updated> <author><name>John Doe</name></author> <!-- Bonus: this summary is extracted from the event data --> <summary type="text">Annual Employee Review</summary> <!-- here is the content, referenced using it's "source representation" media type --> <content src="http://example.org/calendar/1.xcal"; type="application/calendar+xml" /> <!-- Now, the rel="alternate" links to the other two representations --> <link rel="alternate" type="text/calendar" href="http://example.org/calendar/1.ical"; /> <link rel="alternate" type="application/rdf+xml" href="http://example.org/calendar/1.rdf"; /> <!-- The rel="edit" link --> <link rel="edit" type="application/atom+xml" href="http://example.org/calendar/1.atom"; /> <!-- And the rel="edit-media" links --> <link rel="edit-media" type="application/calendar+xml" href="http://example.org/calendar/1.xcs"; /> <link rel="edit-media" type="text/calendar" href="http://example.org/calendar/1.ics"; /> <link rel="edit-media" type="application/rdf+xml" href="http://example.org/calendar/1.rdf"; /> </entry> Please note here that I didn't use conneg at all. So what, does this entry means? « This is an Atom Entry Document representation of a resource whose "source representation"'s media type is "application/calendar+xml" [1]. There also are two alternate representations, with "text/calendar" and "application/rdf+xml" media types respectively [2]. You can edit the Atom Entry Document representation using the "1.atom" URI [3] and/or the other representations using the various "1.xcs", "1.ics" or "1.rdf" URIs [4]. » [1] From content [2] From rel="alternate" links [3] From the rel="edit" link [4] From rel="edit-media" links Note that I definitely think there should only be *one* "Edit URI" (or that other Edit URIs should be "alternate endpoints", without any behavioral difference), it would be really much more simple: - The introspection/service document links to the collection URI using an atom:collection element - The collection feed document links to the entry Edit URIs using a rel="edit" link - The entry retrieved at the Edit URI does not even need a rel="edit" link: if you retrieved it, you already have the Edit URI These are similarities in linking/referencing, here are behavioral similarities: - You can POST anything to the collection URI and an entry will be created. Servers might use "media type dispatching" to route some kind of content through "metadata extractors" (e.g. try to extract the title and author from an ODF document or an MP3's ID3 tags, some geographic information from a JPEG's EXIF headers, etc.) - You can PUT anything to the entry Edit URI and the entry is updated. Servers use "media type dispatching" to determine whether you're editing the Atom Entry Document representation, the "source representation" or another representation of any kind. -- Thomas Broyer
