On Sun, 07 May 2006 10:20:45 -0700, "Tim Bray" <[EMAIL PROTECTED]> said: > Your other points aside, I just don't see a problem here. You do a > POST, and as a consequence two resources are created: one is a "Media > resource" containing whatever the body of your post represented, the > second is a "Media link resource" which, irrespective of what kind of > thing you posted, is represented by an Atom Entry and which describes > the Media resource. Totally within the semantics of POST, I see no > webarch tension here at all. In fact the whole thing feels elegant > and minimal to me. You want to update the metadata package, you > update it. You want to update the picture of the cat, do that too. > The two are decoupled and [important to me] not hard to explain. -Tim
Agreed. In this case, APP cares about two resources: A1. the Atom Entry which provides metadata A2. the Media resource itself plus: A3. the collection feed referencing the above. Which raises my first question: Q1: to what extent is the atom entry in the collection feed identical to / different form the atom entry (A1. above) for GETting/PUTing metadata? Now, in the broader context of an APP-based CMS, there are a couple of other resources potentially involved: A4. a public feed that references the media resource A5. an HTML page that presents the media resource Q2: is it possible (I think it is) that all three Atom entries (A1 and in A3 and A4) differ in what they link to? Now, compare that to the case of an Atom entry whose content is written in HTML inline in the POST to the collection. Presumably in that case we only have: B1. the Atom Entry containing both metadata and the content plus: B2. the collection feed referencing the above (with some or all of the metata) Q3: to what extent is the atom entry in the collection feed identical to / different form the atom entry (B1. above) Q4: are any server implementations inlining the content in this case? Does that even make sense? Again, a broader APP-based CMS would potentially also provide: B3. a public feed that may contain the HTML content inline (or not in the case of summary or title feeds) B4. an HTML page corresponding to the entry (an alternate to the Atom entry) Q5: to what extend are the semantics of content/@src, [EMAIL PROTECTED]"alternate"]/@href, etc identical between B3 and A4? Or B2 and A3? As a third case, what if the HTML in case B were essentially treated as media? So you'd have: C1. the Atom Entry which provides metadata C2. the Media resource itself (HTML) Although this has similarities with case A, presumably it is not quite the same as it is possible to inline the content in feeds. Q6: is this case, in all other respects the same as case A, in contrast with case B? Now imagine a fourth case, similar to case C where the content is written in some wiki-like format but ultimately presented in HTML in public feeds. From a narrow perspective, APP might treat this as identical to case A. So you might have the following resources: D1. an Atom Entry containing metadata D2. a text/x-some-wiki-format Media resource D3. a collection feed that references the text/x-some-wiki-format resource for content editing and the broader CMS would provide: D4. a public feed with inlined HTML converted from the wiki format D5. an HTML page (an alternate) with the converted content But finally consider the case where, from a narrow APP perspective, you want to create and edit the entry as wiki format inlined in the Atom entry. So you just have E1. an Atom Entry with inlined text in the wiki format and E2. a collection feed referencing the above (re-raising Q3 and Q4 above) where a broader CMS would provide: E3. a public feed with inlined HTML converted from the wiki format E4. an HTML page (an alternate) with the converted content Q7: is this just a straight entry collection case like B or a variant of a media collection case like D? I guess I'm fundamentally wondering about the distinctions between media collections and entry collections in light of what I think are 5 distinct use-cases above. Q8: how have the semantics of the various link rels changed from case A to B to C to D to E. Much of this is coming out of a shift from just implementing APP to actually using APP in the context of a broader CMS. But I think it would be good to get clarity on these issues (and my apologies if it's just unclear to me) James -- James Tauber http://jtauber.com/ journeyman of some http://jtauber.com/blog/
