Jan Algermissen wrote: > >> > Hi James, > >> >> On Nov 29, 2006, at 5:16 PM, James M Snell wrote: >> >> >> >>> == Status == >>> >>> Proposed >>> >>> == Rationale == >>> >>> The fact that one media type is used for both Feed and Entry documents >>> has repeatedly come up as a problem on more than one occasion. > > > I took that to refer to the problem I saw (doing an additional check on > the root element) but Mark's comment > made me realize that this is to small of a problem to warrant the media > type separation of something so > tied together, IMO. > > Are there other problems you had in mind when writing the Pace? >
One example. UA POSTs content to a collection. The media type chosen by the client is application/atom+xml and is accepted by the collection. Now say the client posted a feed containing several entries. What should the server decide to do? It could reject the request altogether but on what ground? How to inform properly the UA? If we had a specific media type (or at least a ;type=entry) for Atom entries you would avoid such issue or be able to return a 415 error code. More generally feed and entry documents are semantically distinct enough that they should be distinguished in their media-type one way or the other. I have hard times understanding why it hasn't been done so in the first place. Better be safe than sorry. Well it seems we are sorry :) It's interesting however because now that APP has reached a point where it stable enough to be implemented we can see that issues are not the same for server and client implementors. Considering what happens still now with HTTP (see for instance the Content-Location discussion over at the HTTP-WG) I hope the APP WG and the specification editors are taking great care to limit the possibilities of future conflicts once APP gets heavily deployed and used. If things can safely be changed now then let's do it. - Sylvain
