Re: PaceEntryMediatype

On 12/6/06, James M Snell <[EMAIL PROTECTED]> wrote: Mark Baker wrote: > [snip] > Isn't that just a case of people not implementing the whole spec > though? FWIW, if that practice is widespread, then I think the group > should consider deprecating entry documents. Minting a new media type >

Re: PaceEntryMediatype

On Thu, 07 Dec 2006 13:58:55 +0100, Jan Algermissen <[EMAIL PROTECTED]> wrote: Ok, that is IMO heading in the right direction. This example makes sense because it strongly emphasizes a difference between feeds and entries, saying feeds are for viewing collections and entries are more or less

Re: PaceEntryMediatype

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 evidence that entry documents and feed documents are processed differently and thus de

Re: PaceEntryMediatype

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. I have been wondering if there would not be a case for different mime types if one wanted to place a numbe

Re: AD Evaluation of draft-ietf-atompub-protocol-11

Lisa, Thanks for the very detailed review of this draft. More comments in-line. On 10/17/06, Lisa Dusseault <[EMAIL PROTECTED]> wrote: It would probably not be useful at this point for me to suggest a resolution to absolutely everything, especially if that involves specific wording. It's mu

Re: PaceEntryMediatype

On Thursday, December 07, 2006, at 10:18AM, "Daniel E. Renfer" <[EMAIL PROTECTED]> wrote: >I have two programs on my system; A feed reader, which I use to >subscribe to Atom Feeds, but has a very limited support for Entry >documents; and an APP Editor, which allows me to create and edit Atom >En

Re: PaceEntryMediatype

* Franklin Tse <[EMAIL PROTECTED]> [2006-12-07 10:00]: > If browsers do not support text/plain as a stylesheet, they > should just simply ignore type="text/plain" href="/style.css" />. Exactly. Regards, -- Aristotle Pagaltzis //

Re: PaceEntryMediatype

People in this thread keep asking for a use case where one would want to have a separate mediatype for both feeds and entry documents, so here is my attempt at providing one. I view a web page (blog post) that defines the proper link tags to both the Atom Entry for the current post, and the Atom

RE: PaceEntryMediatype

> What do browsers do with this? > Browsers should get the /style.css, check the Content-Type field of the HTTP Response Header and determine whether they support the stylesheet or not. > And what with this? > If browsers support text/plain as a stylesheet, they should get the /style.css

Re: PaceEntryMediatype

[CC'ing the WHATWG list] 2006/12/7, Jan Algermissen: Seriously: how many feed readers are out there that base the decision wheter something is subscribeable on the type attribute of a link rather then on the link type? Every one? Oh, they also look at the rel="alternate", but I'm pretty sure

Re: PaceEntryMediatype

* Jan Algermissen <[EMAIL PROTECTED]> [2006-12-07 08:25]: > As an analogy: HTML browsers look for stylesheets where it says > > > > and not > > > > Eh? What do browsers do with this? And what with this? Is their behaviour right? Wrong? Why? Regards, -- Aristotle Pagalt

Re: PaceEntryMediatype

On Dec 7, 2006, at 8:41 AM, Sylvain Hellegouarch wrote: Considering you seem to only discuss their value from a feed reader point of view Hmm, strange. Feed readers are actually the last thing I am thinking about wrt Atom (no intention to show disrespect for the blogosphere of course).

Re: PaceEntryMediatype

Jan Algermissen wrote: > > > On Dec 6, 2006, at 11:44 PM, James M Snell wrote: > >> >> I certainly hope you're kidding about dropping entry docs. > > Sure, yes. But your wording IMHO seemed to imply that what feed readers > do should guide a decision. So, given they are not interested in the >