Fwd: PaceEntryMediatype

2006-12-08 Thread Bob Wyman
On 12/5/06, James M Snell <[EMAIL PROTECTED]> wrote: Mark Baker wrote: It's just an entry without a feed. You'd use the same code path to process that entry whether it were found in an entry or feed document, right? Not necessarily... The majority of applications that most frequently handle Ato

Re: Fwd: PaceEntryMediatype

2006-12-08 Thread James M Snell
I'm fine with the type parameter approach so long as it is effective. By effective I mean: Will existing implementations actually take the time to update their behavior to properly handle the optional type parameter. - James Bob Wyman wrote: >[snip] > James suggests: "the type parameter is

Fwd: PaceEntryMediatype

2006-12-08 Thread Bob Wyman
On 11/30/06, James M Snell <[EMAIL PROTECTED]> wrote: > The key problem with "application/atom+xml;type=entry" is that at least > one major browser (Firefox 2.0) still treats it as a feed and shows the > "subscribe" link. So while the type parameter is a potentially more > elegant solution, the

Re: Fwd: PaceEntryMediatype

2006-12-08 Thread James M Snell
Bob Wyman wrote: >[snip] > What you seem to be implying is that the majority of applications > that process Atom Feed documents are not, in fact, supporting extremely > important parts of the atom specification. I believe that any properly >[snip] Not quite. What I'm implying is that not a

Re: PaceEntryMediatype

2006-12-08 Thread Jan Algermissen
On Dec 8, 2006, at 6:49 PM, James M Snell wrote: Not quite. What I'm implying is that not all applications have the need to implement the entire specification. At this point it would be a really good idea to be clear about the original intention of the specification and then propably al

Re: PaceEntryMediatype

2006-12-08 Thread Asbjørn Ulsberg
On Wed, 06 Dec 2006 20:42:40 +0100, Jan Algermissen <[EMAIL PROTECTED]> wrote: But that is an issue of linking semantics, not link target media types. Wrong. The link relation 'alternate' is perfectly valid for both Entry and Feed documents, depending on what type of resource they are li

Re: PaceEntryMediatype

2006-12-08 Thread Asbjørn Ulsberg
On Thu, 07 Dec 2006 20:15:48 +0100, Henry Story <[EMAIL PROTECTED]> wrote: Just to say that I strongly agree with Jan's points below. We should work to use the link relation type properly, and not get dazzled by the current misuse of the alternate relation. This problem isn't only with

Re: PaceEntryMediatype

2006-12-08 Thread Asbjørn Ulsberg
On Thu, 07 Dec 2006 20:37:22 +0100, James M Snell <[EMAIL PROTECTED]> wrote: Content types are only useful when they help to differentiate how a document is to processed. If it was all about the format we could have just used application/xml all along. IMHO, There is already sufficient evi

Re: Fwd: PaceEntryMediatype

2006-12-08 Thread Asbjørn Ulsberg
On Fri, 08 Dec 2006 18:52:05 +0100, James M Snell <[EMAIL PROTECTED]> wrote: I'm fine with the type parameter approach so long as it is effective. By effective I mean: Will existing implementations actually take the time to update their behavior to properly handle the optional type parameter

Re: PaceEntryMediatype

2006-12-08 Thread Mark Baker
On 12/8/06, Asbjørn Ulsberg <[EMAIL PROTECTED]> wrote: On Wed, 06 Dec 2006 20:42:40 +0100, Jan Algermissen <[EMAIL PROTECTED]> wrote: > But that is an issue of linking semantics, not link target media types. Wrong. The link relation 'alternate' is perfectly valid for both Entry and Feed docum

Re: PaceEntryMediatype

2006-12-08 Thread Henry Story
I can see a reason to distinguish more strongly between a feed and an entry. And this is with regards to creating new collections. The best way I see to create a new collection would be to POST a containing no entries to a collection end point. Though that is very similar to POSTing an