On 5/15/06, Robert Yates <[EMAIL PROTECTED]> wrote:
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.
Allowing editing via multiple representations seems like an edge case and not something the core protocol should be optimized for, but I don't think it is disallowed either. That is, as long as you list content/@src as the 'primary' edit location you can list all the other representations via link/@rel='edit-media' links. -joe -- Joe Gregorio http://bitworking.org
