2006/5/9, Tim Bray <[EMAIL PROTECTED]>:
On May 9, 2006, at 8:47 AM, James M Snell wrote: > Would it be appropriate for the server to inline the iCal in the Atom > entry rather than link to it via content/@src. Maybe; but you lose some simplicity. Here's the rule: "If you post something that's not an Atom Entry, you'll get a media resource and a media link entry." Easy to understand.
Well, this is *your* rule. Here's my rule: "If you post anything, you'll get a single resource with, at a minimum, an Atom Entry Document representation." Even easier to understand, as there is a single rule whether you post an Atom Entry or not. You just need to be a bit familiar with the WebArch, but that's not big deal.
If you want to achieve the effect you describe, put the text/calendar stuff in the content of an Atom Entry and post that. What am I missing?
This is not really compatible with WebDAV (which was a WG goal IIRC), or at least the mapping is not really straitforward. For example, the atom:author elements in the "media link entry" tells you the authors of the "media resource", that's it? This means you a have a "media resource" and another resource that's just "describing" that "media resource". If I want to make my APP server WebDAV-compliant, I have to support PROPFIND. I'd say that issuing a PROPFIND on the "media resource" URI might return those atom:author elements as properties of the "media resource" (that'd be OK, since the atom:author elements tells you the authors of the "media resource"; my server could even use conneg to deliver an Atom Entry instead of the WebDAV's propfind document), and I could update them using a PROPPATCH on the same URI. This would mean that by updating the "media resource" metadata using PROPPATCH, I'd automatically change the "media link entry" resource, and by updating the "media link entry" resource using PUT, I'd automatically change the "media resource" metadata. That would work, but it's not straitforward. But maybe the atom:author elements indicate the authors of the "media link entry" resource, not the ones of the "media resource" (as they are distinct resources per your rule, they might have distinct authors)? Let's complicate the thing a little bit more and talk about atom:updated. The atom:updated element value tells you the date and time the resource has been modified in a "significant" way (at the publisher's discretion). Does it apply to the "media link entry" or the "media resource"? or both? Could I have distinct atom:updated when issuing a PROPFIND on the "media resource" and retrieving the Atom Entry representation of the "media link entry" resource? Do you want a bit more brain torture? Given that the "media resource" URI is given as the atom:content of the "media link entry", it can be either inlined or referenced using the "src" attribute. RFC4287 doesn't say much about it but my reading is that inlined and out-of-line content have the same semantic: the entry content. So how do you call the "media link entry" resource if the content is inlined? Is this « the same as the "media resource" with embedded metadata »? This looks like just a representation matter: the resource has two representations, one without "atom" metadata and one with embedded metadata in the form of an Atom Entry. The "out-of-line" content is then just an optimization trick to save bandwidth when the content is also retrievable at a distinct URI (when a resource has more than one URI, each one serving a single representation, or at least sets of representations that don't overlap). Now, let's get back to my fictional WebDAV-compliant APP server implementation. As the "media link entry" gives metadata about the "media resource", I might also just want to hide the "media link entry" and let "atom metadata" be edited only using PROPFIND/PROPPATCH on the "media resource". A WebDAV client would then have no mean of deleting the resource, as the DELETE request should go to the "media link entry" resource. There would probably be similar issues wrt other WebDAV methods, such as COPY or MOVE. Oh, and how about versionning? Wouldn't it be far easier if there were only *one* resource, with two representations? My vision is that AtomProtocol's POST is identical to the proposed WebDAV's ADDMEMBER (which in turn is just identical to a PUT to a null resource where you let the server choosing the IRI). GET to a collection is similar to PROPFIND to a collection in order to discover the collection's membership (PROPFIND with a "Depth: 1" header). GET/PUT of an Atom Entry Document is similar to PROPFIND/PROPPATCH to retrieve/update properties/metadata (if the resource is an entry, rather than "file", then GET/PUT is also equivalent to WebDAV's GET/PUT of a resource's representation). GET/PUT of a non-Atom representation is identical to WebDAV's GET/PUT. And finally DELETE is identical to WebDAV's DELETE (be careful about WebDAV Binding Extensions compatibility here!) So actually, the only "design" difference between the AtomProtocol and WebDAV would be than any resource has at least an Atom Entry Document representation. If you initially POSTed a non-AtomEntry representation, the Atom Entry Document representation is probably hidden to WebDAV clients (if metadata is editable using PROPFIND/PROPPATCH). As the WG thinks conneg shouldn't be a required component of the AtomProtocol, those alternate representations might (must? [*]) be accessible at distinct URIs. A WebDAV+AtomProtocol implementation might allow the creation of resources using PUT, then the atom:id (to be able to find the Atom Entry in the "collection feed") would then be retrieved using PROPFIND. If the implementation also supports the WebDAV Binding Extensions, the atom:id would probably be the same as the DAV:resource-id property. [*] I think the WG consensus is that conneg shouldn't be required on the server's side, but it's real easy for clients to adapt their Accept request-header field value when they want to retrieve a specific representation. My opinion is that APP-clients SHOULD be prepared to handle server-negotiated resource/representations, so SHOULD adapt their Accept request-header field depending on which kind of representation they want to retrieve. As a Good Practice, I'd suggest always including "*/*", in case the media type "hint" they might have is inaccurate. This means that when the Atom Entry says <atom:content src="x" type="image/jpeg"/>, clients should use, at a minimum, "Accept: image/jpeg, */*" so that they will be given an image/png for example if no image/jpeg representation is available, not a 406 (Unacceptable) error response. -- Thomas Broyer
