> My assumption: a client cannot create a media resource without also > creating a media link entry. When I POST a media resource to a > collection, a media link entry is *always* created.
Same here. Lisa what do you mean by creating a media resource manually? If you do not use an APP service to create a media resource then it does not fall into APP to tell how this resource will be accessible. To me it's like it's not even part of the collection. > >> - To an outsider or newcomer -- including me even though I've been >> following discussions closely for a while -- there's a part of the Atom >> model that's subtle but important to understand. Consumers of Atom >> feeds are supposed to look at the regular feed document, whereas >> publishers of Atom feeds are supposed to look at other, different >> resources to see how to edit or create posts. Publishers effectively >> look at a different feed than users do, one with extra metadata (the >> rel="edit" links). It's a different model than that of WebDAV or IMAP, >> because rather than have the client specify which metadata it's >> interested in, the server offers two choices with different addresses. >> I believe it would be useful to cover that part of the model upfront in >> addition to the other useful stuff already there. >> > > My assumption: The separation between "subscription feeds" and > "collection feeds" is not always clear. There are at least two deployed > implementations I am aware of that use the same feeds for both and I'm > currently working on a third. In Google's new Blogger Beta, for > instance, the subscription feed is also the collection feed. I would rather have distinct feed for both always but ultimately it's still just an atom feed. Atom rules apply the same way in both cases. I fail to find a case where it can be a real issue to use the same feed. > > I believe that any assumption that the subscription and collections > feeds will always be different is incorrect and dangerous. > >> *Creating resources* >> >> Explicit result of POST, section 4. >> >> Are there zero, one or more resources created with a POST? There's a >> line at the top of section 4 which says that "POST is used to create a >> new, dynamically-named, resource". However, that implies ONE, whereas >> with media entries, a POST could create TWO resources. I believe a >> successful POST request as described here MUST either result in one or >> two resources, never zero, and never 3 or more (in the absence of >> extensions). Section 9.5 says: A client can POST a media type other than application/atom+xml to a Collection. Such a request creates two new resources - one that corresponds to the entity sent in the request, called the Media Resource, and an associated Member Entry, called the Media Link Entry. I find that quite clear at least regarding media resource. > >> What is the expected behavior of seeing a POST to an entry URL (rather >> than a collection URL)? I see that this is currently undefined; it may >> be worth stating that to warn clients. (I'm pretty indifferent on this >> one, as in this case I can't see any obvious harm in different server >> behaviors existing, if un-warned clients try it intentionally without >> knowing the results. The only possible harm is if clients got confused, >> did a POST to an entry URL when a collection URL was intended, and the >> server does a success response which creates new resources or modifies >> existing resources in a way the client did not expect. An error >> response would certainly be harmless for this undefined case but a >> success response could be real interesting.) I would say a server not sending a 405 or any other 40x is broken in that case. > >> Creating entries with multiple media resources >> >> It's never explained how a client would go about creating a feed entry >> with a number of media resources. I imagine that it could be iterative; >> a client could create any of the resources at any time, and at any time >> after creating the feed entry, use PUT to update the feed entry to link >> to new media resources. I assume -- though I didn't see it stated in >> the document -- that it's the client's responsibility in almost all >> cases to put links in the feed entry to point to the media resources, >> otherwise the media resources are unlinked (effectively hidden to >> readers). >> > > My assumption: The relationship between a media link entry and a media > resource is always 1-to-1. If I want an entry to point to multiple > media resources, then I would create one media link entry for each media > resource, then create a separate entry that points to each of the > individually created media resources. > > e.g., > > entry1 --> pic1 > entry2 --> pic2 > entry3 --> pic3 > entry4 --> pic1 > --> pic2 > --> pic3 > > Entries 1, 2 and 3 will always point to their respective media resources > (using atom:content/@src). +1 > >> The exception to this general process is if the client first uses POST >> to create both the media resource and the "Media Link Entry" in one go. >> In this case, can the "Media Link Entry" (MLE) be transformed to a >> regular "Member Entry Resource" (MER)? I thought it would be possible, >> but discussed just a bit with Tim today and he says no, so there you >> have two different readings of the spec. I guess a related question is >> what would happen if a client does a PUT of media content to an entry >> resource, or entry content to a media resource. >> > > My assumption: I had originally wanted the ability to change "MLE" into > a "MER" but the general consensus of the WG seemed to be leading in the > other direction. Once a media link entry is created, it cannot be > changed into some other kind of thing. I personally think that's bogus, > but... > > Regarding what would happen if a client does attempt to change the type > of resource, that's undefined. In my current implementation, the new > content would be silently discarded, which is bogus. I'll likely change > the behavior so that the request is rejected. I think we had that discussion a few weeks ago and it had been agreed that a PUT could change the type of the MLE. I do hope the WG will draw a clear line on that matter because I won't have the possibility to chit-chat with Tim myself to know about it... > >> It's not clear to me whether a linked media entry is always listed in >> the metadata or not. > > My assumption: Yes Same here. > >> - When one or more "edit-media" link relations appear, who has been >> responsible for putting them there? > > My assumption: the Server APP should maybe rule out that if a 'edita-media' appears there can only be one. > >> - When a media resource is deleted, who is responsible for removing the >> media resource link from the MLE? > > My assumption: the Server. When the media resource is deleted, the > associated MLE SHOULD also be deleted. Agreed however... it would be nice if section 9.4 could explain it that way. Currently it only mentions the deletion of the MLE itself resulting in the deletion of the media resource. >> Can a client modify an entry to contain a link relation element in the >> following cases: >> - To result in an "edit" or "edit-media" link relation, where the >> resource represented does not meet the requirements in section 11.1 or 11.2? >> - To result in an "edit" link relation that actually points to a media >> resource, or a "edit-media" link relation that actually points to a MER? > > My assumption: the server is responsible for adding the edit and > edit-media links. Clients are not allowed to modify these values. Agreed. Servers should silently disregard modification to those links. > >> - To point to a resource on a different server entirely? >> - To point to a valid media resource or MER that happen to be in a >> different collection than the one normally used for this feed? >> - Will some servers forbid adding a link relation element entirely? Is >> it important for the client to know that that will always be forbidden >> for that server -- can it detect the "always forbidden" case separately >> from the "this particular edit is forbidden" case? > > My assumption: the decision is ultimately up to individual server > implementations, but in general clients should be allowed to add/edit > all link relations other than the edit and edit-media links. It is > unlikely, however, that your typical blog implementation of APP would > allow a client to modify the alternate link relation. Agreed. > >> Multiple formats/langs for media resources >> >> Multiple formats are not sufficiently defined -- e.g. JPG and PNG >> versions of an image resource. Format negotiation is hard. I found >> guidance for how to select among different "edit-media" link relations >> depending on format and language, but I found no guidance on how to >> create multiple versions. If there's no guidance to clients or servers >> how to do it (would the client create multiple resources in different >> formats? > > Yes. > >> could the server automatically do it as variants? > > Yes. > >> could the server automatically do it as multiple resources, and would > all formats >> be therefore listed?), > > Yes. > >> it's probably worth considering whether there's >> possible interoperability harm here. > > The behavior is ultimately up to the server. No normative behavior > should be specified (largely because we're not yet sure what all folks > will actually want to do). Much agreed with James again. > > My assumption: IMHO, this recommendation no longer unnecessary given > that our recent decision to require that the Location header always > point to the Edit URI of the resource created. I'd prefer that it be > removed. Agreed with James. > > My assumption: If a client DELETE's a MLE, it's associated media > resource SHOULD be deleted. If the client DELETE's the media resource, > the MLE SHOULD be deleted. If the client DELETE's an entry that links > to a media resource in any other way (e.g. there is some other kind of > link relation or an img tag in html content, etc) then the "correct" > behavior is up to the server. Agreed. > >> Can collections be DELETEd? It's fine for servers to allow or no, but >> if servers don't support, what error to use. >> > > My assumption: It's up to the server. 405 Method Not Allowed. Indeed. After all APP is based on HTTP so let's use HTTP error codes. > >> *Editing resources* >> >> Overall, the process for editing a resource is not entirely clear. I >> find the description of creating a resource (POST), and what the server >> can accept, ignore or reject, more clear than the description of editing >> a resource (PUT) . For example, there's normative text in section 9.2.1 >> (an example) relative to creating resources and handling metadata, but >> that text isn't duplicated for editing resources or obviously apply to >> editing resources. Thus: >> - Can the client change the category? (probably yes; MUST the server >> allow?) > > Generally Yes. It's up to the server. I would say yes as well. I think there are only a very limited set of elements client MUST NOT be allowed to edit: id, edit and edit-media links, content, published, update, edited. IMO the rest should be safe for modification. > > In my impl, the server will always report all of the operations that can > be applied to a resource, regardless of whether the current user is > allowed to use those methods. A collection, for instance, will always > specify (at a minimum) the GET and POST methods. An Edit URI will > always specify (at a minimum) the GET, PUT and DELETE methods. Same in my implementation - Sylvain
