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. While it works, I question forcing
connection negotiation on developers, and it also suffers from not being
able to advertise to the client the types of representations
available.. I would prefer the flexibility of being able to return.
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>
<link rel="edit" type="application/atom+xml"
href="http://example.org/calendar/1.atom"; />
<link rel="alternate" type="application/calendar+xml"
href="http://example.org/calendar/1.xml"; />
<link rel="alternate" type="text/calendar"
href="http://example.org/calendar/1.ics"; />
<link rel="alternate" type="application/rdf+xml"
href="http://example.org/calendar/1.rdf"; />
<link rel="edit-media" type="application/calendar+xml"
href="http://example.org/calendar/1.xml"; />
<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>
With this approach the server creates an ATOM entry, but is not mandated
to place a link to the media in the content/@src attribute. It can,
instead, return any valid atom entry with as many representation of the
content as it wishes. The example includes links to the three alternate
representations (note that it doesn't even need a summary element). I'd
like to suggest that MediaEntries4 remove the mandate to place the
content's url in the content/@src and instead be allowed to return any
valid atom entry. The atom entry can indicate editable representations
of the content through the use of the "edit-media" link relationship.
Rob
