Re: PaceEntryMediatype
Bob Wyman wrote: On 12/10/06, Eric Scheid [EMAIL PROTECTED] wrote: The only danger [of defining a new media type] is if someone has implemented APP per the moving target which is Draft-[n++] ... they should revise their test implementations as the draft updates, and certainly update once it reaches RFC status, so no sympathies there. The impact here is not just limited to APP implementations. If a new media type is defined, it will undoubtedly appear in other contexts as well. Given the current definition of the atom syntax, it is perfectly reasonable for an aggregator to treat a single entry as the semantic equivelant of a single-entry feed. If a new media type is defined, such an application would end up having to be modified. That's not right... APP is not the only context within which Atom is used. I still don't understand the meaning of equivalence between an entry document and a single-entry-feed document. I have read your other message and I'm still nowhere near an understanding of it. In fine if you accept that an entry document is just equivalent to a single-entry-feed you have to detail precisely how this equivalence takes place and can be measured. Is it based on the atom:id? If yes is it on the atom:id of the entry or the feed? Is it based on its metadata? Again which ones since an entry embedded in a feed can overwrite the feed metadata. You should also explain why we have entry document at all if they are equivalent to single-entry-feed ones. Moreover you claim that it's going to break implementations. Which ones? How? Why? Can't those applications be updated? Why shouldn't APP be set straight because of those applications? There is a large feeling on the WG that there could be a use for distinction at the message level. We all acknowledge that could be disruptive but I don't think I can agree that it would bring down a all set of applications. You say those in favor haven't brought good use cases but neither have you. - Sylvain
Re: PaceEntryMediatype
Bob Wyman wrote: The impact here is not just limited to APP implementations. If a new media type is defined, it will undoubtedly appear in other contexts as well. Given the current definition of the atom syntax, it is perfectly reasonable for an aggregator to treat a single entry as the semantic equivelant of a single-entry feed. I don't agree. atom:source is optional, and even then that does not cater for situations where entries have been annotated downstream. If a new media type is defined, such an application would end up having to be modified. That's not right... APP is not the only context within which Atom is used. What matters is whether atom:feed is the only context within which atom:entry is used, and/or whether atom:entry is an atom:feed in masquerade. After who knows how many posts and having gone back to the RFC, as I see it, neither of those is true or supported by the spec. There'll have to be another rationale presented for not spinning out a new media type. cheers Bill
Re: PaceEntryMediatype
On 11/12/06 2:26 PM, Joe Gregorio [EMAIL PROTECTED] wrote: Adding an optional parameter that indicated an entry or a feed would be a more elegant solution: application/atom+xml;type=entry application/atom+xml;type=feed I certainly agree it would be more elegant. A more pragmatic solution would be to go with application/atom.entry+xml ... if WHATWG don't update their spec, we're safe; if anyone has implemented per the current draft WHATWG spec, we're safe; if any implementations use naïve string matching, we're safe. The only danger is if someone has implemented APP per the moving target which is Draft-[n++] ... they should revise their test implementations as the draft updates, and certainly update once it reaches RFC status, so no sympathies there. e.
Re: PaceEntryMediatype
On 12/10/06, Eric Scheid [EMAIL PROTECTED] wrote: The only danger [of defining a new media type] is if someone has implemented APP per the moving target which is Draft-[n++] ... they should revise their test implementations as the draft updates, and certainly update once it reaches RFC status, so no sympathies there. The impact here is not just limited to APP implementations. If a new media type is defined, it will undoubtedly appear in other contexts as well. Given the current definition of the atom syntax, it is perfectly reasonable for an aggregator to treat a single entry as the semantic equivelant of a single-entry feed. If a new media type is defined, such an application would end up having to be modified. That's not right... APP is not the only context within which Atom is used. bob wyman
Re: PaceEntryMediatype
On Dec 9, 2006, at 6:40 AM, Mark Baker wrote: On 12/8/06, Asbjørn Ulsberg [EMAIL PROTECTED] wrote: Both link relations are identical, but the client has absolutely no clue before it GETs the URI whether what sits on the other end is an Atom Feed or an Atom Entry. Nor should it need to distinguish Asbjørn, the link is to the resource, not a particular representation of it. The media type is just a hint, what you get upon a GET can vary and your client should prepare for that. You can make use of that hint, but it does in no way tell you what the actual media type is you'll get upon a GET; it is not authoritative, the Content-Type header is. What you can rely on is that the server uses the correct link relation. IOW, that the server informs you about the relationship correctly, that it does not tell you X is an alternate of A if it isn't. Something else: Suppose there were two representation formats for atom feeds one in XML and one in some space optimized text format. Conceptually they server up the same information - what type goes into the type attribute? And yet in other words: Media type are telling you hw to process a representation, not of what kind the resource is (resources are not typed, BTW). Jan
Re: PaceEntryMediatype
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 align the specs with that as opposed to having software that only implements half of a specs. People out there might be caused to think this is good practice Jan
Re: PaceEntryMediatype
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 linked from. An index page of a website can have an 'alternate' relation to an Atom Feed, while an individual article page (or entry page) can have an 'alternate' relation to an Atom Entry. Both link relations are identical, but the client has absolutely no clue before it GETs the URI whether what sits on the other end is an Atom Feed or an Atom Entry. Let's take Firefox as an example of a feed reader. When you browse to a page saying it has 'alternate' resources, you get a nice little orange subscribe button in the address field. Pushing it makes you a subscriber of that alternate resource. On an index page, that's fine, because the alternate resource is an Atom Feed. However, on an individual article page, Firefox will still display the subscribe button although it doesn't support subscribtion to the resource and subscribing to it in the first place doesn't make much sense. Wouldn't it be a better experience to not get the subscribe button on the article page at all? Or do you prefer that it's there and that you need to press it and get an error message (that you most probably won't understand if you're not a technical user like you and me) to know that you can't subscribe to this alternate resource after all? What do you think? I'd expect the user agent to look for links with 'here is a feed' semantics instead of looking for (arbitrary) links to certain media types. The 'alternate' relation is fine for both uses. However, the WHATWG propsed 'feed' relation is a bit more explicit on the subscribe to me part. Still, an Atom Feed can be 'alternate' of an index page just as an Atom Entry can be 'alternate' of an article page. People shouldn't be forced to use the 'feed' relation, and I highly doubt that the widely deployed 'alternate' relation can be replaced that easilly. -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: PaceEntryMediatype
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 documents, depending on what type of resource they are linked from. An index page of a website can have an 'alternate' relation to an Atom Feed, while an individual article page (or entry page) can have an 'alternate' relation to an Atom Entry. As it can to a feed with one entry. Both link relations are identical, but the client has absolutely no clue before it GETs the URI whether what sits on the other end is an Atom Feed or an Atom Entry. Nor should it need to distinguish, just like it doesn't need to distinguish between a feed with multiple entries, versus one with one entry. Mark.
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 entries, dropping them is not too farfetched, is it? Let's just label 'em differently and move on. I still do not see the use cases justifying a new media type - it might be the right thing to do but for the time being it looks like a workaround. Considering you seem to only discuss their value from a feed reader point of view, I'm not surprised you don't see the use for at least minting the current media-type, let alone an entirely new one. I think at this stage having further discussion won't help anymore and I would like the WG-chairmans and editors to tell us what they think about this issue because we aren't going anywhere right now. - Sylvain Jan - James Jan Algermissen wrote: On Dec 6, 2006, at 11:30 PM, James M Snell wrote: Jan Algermissen wrote: [snip] So they should be fixed, should they not? They seem to only have implemented half a media type. The half they're interested in. Why aren't they interested in the other half? Ha! Forget about the media type - let's drop entry documents. Jan - James
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). Jan
Re: PaceEntryMediatype
* Jan Algermissen [EMAIL PROTECTED] [2006-12-07 08:25]: As an analogy: HTML browsers look for stylesheets where it says link rel=stylesheet type=text/css href=/style.css / and not link rel=alternate type=text/css href=/style.css / Eh? What do browsers do with this? link rel=stylesheet href=/style.css / And what with this? link rel=stylesheet type=text/plain href=/style.css / Is their behaviour right? Wrong? Why? Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
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 they won't process the link if the 'type' attribute is absent, and they don't process it if it's present with a value different from the Atom or RSS media type. As an analogy: HTML browsers look for stylesheets where it says link rel=stylesheet type=text/css href=/style.css / and not link rel=alternate type=text/css href=/style.css / Eh? Let's take two files, index.html and style.css. Now, let's describe the relationship between them. What is style.css wrt index.html? a stylesheet that browsers should use to present index.html. What is index.html wrt style.css? a page that uses style.css as a stylesheet. The relation really *is* stylesheet (when taken from the page to the stylesheet), whether it is written in CSS, XSLT-XSL-FO, DSSSL, etc. Now, let's take a blog entry page and the blog feed and try to describe the relationship between them. What is the blog entry page wrt the blog feed? a resource that is being or has been linked from the feed as one of its items. If you see a feed as a set of entries not restricted to the limited set exposed by its representations, the entry is still part of the feed. What is the blog feed wrt the blog entry page? a feed (set of entries, bla bla bla) which is linking or has been linking to the entry page as one of its items. The relation in this case is feed (when taken from the entry page to the feed; note that rel=feed here is *not* the same as the one from the current HTML5 draft). What's clear is that it is not alternate, as used today for feed autodiscovery. This rel=feed is IMO useful because that's what people are generally looking at when they want to subscribe to a site and are not already looking at an HTML feed: where's the feed which contains this item? Last example, in two parts: Let's start with Mozillazine's homepage and its Atom0.3 feed; they are clearly rel=alternate representations of the same thing: a feed (set of entries, bla bla bla). The HTML version also contains sidebars with additional information, but they're not part of the main content. Now, let's take, say the Mozilla.org homepage. It is linking to Mozillazine and its feed. I don't know how we could describe the relationship between Mozilla.org and Mozillazine and that's not the point here, so let's call it X. If Mozilla.org is linking to Mozillazine using rel=X and given that Mozillazine's homepage and Atom0.3 feed are alternates; Mozilla.org should also be linking to Mozillazine's Atom0.3 feed using rel=X (which it does in an a in the body of the page, where actually it uses no rel= at all). So why the hell is it using rel=alternate? (in a link in the head section). As Mozillazine's Atom0.3 feed is an alternate representation of the Mozillazine's homepage, does it mean that Mozilla.org and Mozillazine also are rel=alternate? I'd say no, however that's what rel=alternate implies (it has been re-enforced in HTML5 that rel=alternate is transitive). If rel= on a and area had a default value (let's say rel=related), then this value could be used in the required rel= attribute of link when linking to feeds which are neither rel=alternate or rel=feed (with the definition given above, *not* the one from HTML5): link rel=related href=http://www.mozilazine.org/atom.xml; type=application/atom+xml title=Mozillazine News My last point: if the rel=feed as described above seems useless, then I'm not opposed to having a rel=feed marker as defined in the current HTML5 draft, with an addition: that this feed marker be combinable with any link rel: rel=feed alternate, rel=feed up, rel=feed index, etc. (and at the condition that it is explicitely defined as a marker and not as a relationship; rel=prefetch and rel=nofollow would also need this distinction). -- Thomas Broyer
RE: PaceEntryMediatype
What do browsers do with this? link rel=stylesheet href=/style.css / 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? link rel=stylesheet type=text/plain href=/style.css / If browsers support text/plain as a stylesheet, they should get the /style.css and use the Content-Type field of the HTTP Response Header to confirm whether they really support the stylesheet. If browsers do not support text/plain as a stylesheet, they should just simply ignore link rel=stylesheet type=text/plain href=/style.css /. Franklin Tse -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of A. Pagaltzis Sent: Thursday, December 07, 2006 16:14 To: atom-syntax@imc.org Subject: Re: PaceEntryMediatype * Jan Algermissen [EMAIL PROTECTED] [2006-12-07 08:25]: As an analogy: HTML browsers look for stylesheets where it says link rel=stylesheet type=text/css href=/style.css / and not link rel=alternate type=text/css href=/style.css / Eh? What do browsers do with this? link rel=stylesheet href=/style.css / And what with this? link rel=stylesheet type=text/plain href=/style.css / Is their behaviour right? Wrong? Why? Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
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 Feed for all the posts on that blog. These links have the proper type and rel information attached to each respective links. No problem there, the browser can decide what to do with those links based off rel information alone. Now, in the template of this page, the author also includes standard html anchors to these two resources for the benefit of users using a browser that doesn't understand Atom Entries let alone Atom Feeds. He's linked the feed to a png image of the standard feed icon, and a similar image for the Entry. These anchors have @href attributes, but no @type or @rel information. 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 Entries, but has limited support for Feeds. If I click on one of these two links on the page, I want that resource to be handled by it's respective program. If these two documents were each to be served with a different mediatype, then it is trivial to tell my OS/Browser to send the Feeds to my feed reader, but send my Entries to my editor. As it stands right now, there would be no way to do this aside from having a third program taking in both, sniffing the content and sending the document to the appropriate program. This is a horrible solution. The @rel attribute is still useful. The @rel exists to tell the browser what to do with the document, the @type exists to say what that document actually IS. I dislike the idea of using ;type=[feed|entry] mostly because I'm afraid that this information will far too likely be either diregarded or dropped. Also, once Entries become their own type, the next logical step would be to have something like: application/atom.entry+xml;type=xhtml application/atom.entry+xml;type=html application/atom.entry+xml;type=text application/atom.entry+xml;type=markdown etc... Of course, let's reach a consensus on this issue before that particular can of worms gets opened up. Daniel E. Renfer http://kronkltd.net/ On 12/7/06, Jan Algermissen [EMAIL PROTECTED] wrote: 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). Jan
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 link rel=stylesheet type=text/plain href=/style.css /. Exactly. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
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 Entries, but has limited support for Feeds. If I click on one of these two links on the page, I want that resource to be handled by it's respective program. If these two documents were each to be served with a different mediatype, then it is trivial to tell my OS/Browser to send the Feeds to my feed reader, but send my Entries to my editor. 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 for editing web resources (if we include the media resource case). If the Atom specs never considered feed readers to be dealing with individual entries anyhow (at least that is the impression I get by now) then having a new media type does indeed make sense. Question to Atom editors and others involved with the specs: What was the intention behind having entry documents in Atom in the first place? Thanks, Jan As it stands right now, there would be no way to do this aside from having a third program taking in both, sniffing the content and sending the document to the appropriate program. This is a horrible solution. The @rel attribute is still useful. The @rel exists to tell the browser what to do with the document, the @type exists to say what that document actually IS. I dislike the idea of using ;type=[feed|entry] mostly because I'm afraid that this information will far too likely be either diregarded or dropped. Also, once Entries become their own type, the next logical step would be to have something like: application/atom.entry+xml;type=xhtml application/atom.entry+xml;type=html application/atom.entry+xml;type=text application/atom.entry+xml;type=markdown etc... Of course, let's reach a consensus on this issue before that particular can of worms gets opened up. Daniel E. Renfer http://kronkltd.net/ On 12/7/06, Jan Algermissen [EMAIL PROTECTED] wrote: 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). Jan
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 number of representations at the same url. One could for example have the following at the same place: - an html version of a blog post - an entry representation of that blog post - a feed for the history of changes to that blog post That would suggest having different media types because one could not place them at the same location if one only has application/atom +xml . That does not decide the issue as to whether it is a good idea to do so. For the moment I find the application/atom+xml;type=entry application/ atom+xml;type=feed more appealing than the other new media types by the way. On the other hand having different mime types for every document format is also crazy. If someone invents a doc to describe cats, and someone else a doc to describe mice, are they going to need a new mime type? And what about a doc to describe policemen, and a doc to describe people? We could end up quickly with an infinite number of mime types which clearly would not help interoperability. Henry On 6 Dec 2006, at 23:22, Jan Algermissen wrote: On Dec 7, 2006, at 7:43 AM, A. Pagaltzis wrote: It seems pointless for atom:link to have a type attribute at all then. You should be able to decide anything you need to decide by GETting the resource (and sometimes parsing it). Why did we add such a useless feature to the spec? I am pretty sure it wasn't added for being able to tell people: Look, at the other end of this link is a feed. 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? As an analogy: HTML browsers look for stylesheets where it says link rel=stylesheet type=text/css href=/style.css / and not link rel=alternate type=text/css href=/style.css / Eh? Jan On 6 Dec 2006, at 11:42, Jan Algermissen wrote: On Wednesday, December 06, 2006, at 08:30PM, Antone Roundy [EMAIL PROTECTED] wrote: On Dec 6, 2006, at 12:14 PM, Jan Algermissen wrote: I'd say: stick with the one media type that is currently there - there is no problem, just misconception about what it means to subscribe. A few reasons why a user agent might want to be able to tell the difference between a link to a feed and a link to an entry beforehand is in order to: But that is an issue of linking semantics, not link target media types. I'd expect the user agent to look for links with 'here is a feed' semantics instead of looking for (arbitrary) links to certain media types. IMHO, there is something going wrong somewhere - and it ain't the media type. I completely agree. On 6 Dec 2006, at 14:26, Jan Algermissen wrote: To make that decision, the agent has to look at the representation and the it is insignificant overhead to see if the thing returnes feed or entry. Not if the resource needn't be GET in the first place. If the whole operation can be decided upon the Content-Type returned in a HEAD request, or Ok, HEAD would save the extra payload, butI still think the reason for subscribing is NOT how the representation at the other end looks, it is based on the link semantics.
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 deserve different content types. - James Henry Story 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. I have been wondering if there would not be a case for different mime types if one wanted to place a number of representations at the same url. One could for example have the following at the same place: - an html version of a blog post - an entry representation of that blog post - a feed for the history of changes to that blog post That would suggest having different media types because one could not place them at the same location if one only has application/atom+xml . That does not decide the issue as to whether it is a good idea to do so. For the moment I find the application/atom+xml;type=entry application/atom+xml;type=feed more appealing than the other new media types by the way. On the other hand having different mime types for every document format is also crazy. If someone invents a doc to describe cats, and someone else a doc to describe mice, are they going to need a new mime type? And what about a doc to describe policemen, and a doc to describe people? We could end up quickly with an infinite number of mime types which clearly would not help interoperability. Henry On 6 Dec 2006, at 23:22, Jan Algermissen wrote: On Dec 7, 2006, at 7:43 AM, A. Pagaltzis wrote: It seems pointless for atom:link to have a type attribute at all then. You should be able to decide anything you need to decide by GETting the resource (and sometimes parsing it). Why did we add such a useless feature to the spec? I am pretty sure it wasn't added for being able to tell people: Look, at the other end of this link is a feed. 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? As an analogy: HTML browsers look for stylesheets where it says link rel=stylesheet type=text/css href=/style.css / and not link rel=alternate type=text/css href=/style.css / Eh? Jan On 6 Dec 2006, at 11:42, Jan Algermissen wrote: On Wednesday, December 06, 2006, at 08:30PM, Antone Roundy [EMAIL PROTECTED] wrote: On Dec 6, 2006, at 12:14 PM, Jan Algermissen wrote: I'd say: stick with the one media type that is currently there - there is no problem, just misconception about what it means to subscribe. A few reasons why a user agent might want to be able to tell the difference between a link to a feed and a link to an entry beforehand is in order to: But that is an issue of linking semantics, not link target media types. I'd expect the user agent to look for links with 'here is a feed' semantics instead of looking for (arbitrary) links to certain media types. IMHO, there is something going wrong somewhere - and it ain't the media type. I completely agree. On 6 Dec 2006, at 14:26, Jan Algermissen wrote: To make that decision, the agent has to look at the representation and the it is insignificant overhead to see if the thing returnes feed or entry. Not if the resource needn't be GET in the first place. If the whole operation can be decided upon the Content-Type returned in a HEAD request, or Ok, HEAD would save the extra payload, butI still think the reason for subscribing is NOT how the representation at the other end looks, it is based on the link semantics.
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 for editing web resources (if we include the media resource case). Yay, the discussion is progressing! :) If the Atom specs never considered feed readers to be dealing with individual entries anyhow (at least that is the impression I get by now) then having a new media type does indeed make sense. Yes indeed. Question to Atom editors and others involved with the specs: What was the intention behind having entry documents in Atom in the first place? I don't remember all about the original discussion, but here's three of my entries from back in the days: http://www.imc.org/atom-syntax/mail-archive/msg04647.html http://www.imc.org/atom-syntax/mail-archive/msg04386.html http://www.imc.org/atom-syntax/mail-archive/msg08599.html Although the topics in which the messages appear are unrelated, they all talk about the same thing, namely having Atom Entries as first-class web citizens. Back then, reaching this goal was enough of a struggle; defining Atom Entries' own MIME type was unthinkable. -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
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 won't help. The interesting question is *why* haven't those applications implemented support for Entry Documents. My guess is that Entry documents aren't particularly interesting to their use cases which is likely because they serve a different purpose. Makes sense. I forgot that entry documents were used for creation in APP. But serving different purposes does not necessitate a different media type. Both Firefox and Googlebot are voracious consumers of text/html documents, yet for very different purposes. Mark.
Re: PaceEntryMediatype
* Mark Baker [EMAIL PROTECTED] [2006-12-04 21:35]: If it looks like an alias, and acts like an alias ... 8-) It doesn’t. For resource creation this specification only defines cases where the POST body has an Atom Entry entity declared as an Atom media type (application/atom+xml), or a non-Atom entity declared as a non-Atom media type. It does not specify any request semantics or server behavior in the case where the POSTed media-type is application/atom+xml but the body is something other than an Atom Entry. In particular, what happens on POSTing an Atom Feed Document to a Collection using the application/atom+xml media type is undefined. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: PaceEntryMediatype
Mark Baker wrote: The real problem here AIUI - at least in the context of HTML 5's inferred rel=feed bit - is not just entry documents, it's any Atom document which wouldn't normally be considered a feed by a typical user; something that most people would be interested in subscribing to. An example I gave on the whatwg list was an MHTML-like (MIME multipart) package, but there are many other possible examples of course; not all RFC 4287 feed documents are feeds in this sense. If HTML 5 (and current practice) doesn't change, but we defer to them for the specification of autodiscovery, then a new media type would be one way forward. But it should be reusable for all non-feed (i.e. from a user POV, as above) Atom documents, not just entry documents; perhaps application/atom-no-feed+xml. It's an ugly hack, but it's better than the alternative of many more specific Atom-related media types, which atomentry+xml might set a precedent for. Note that HTML 5's special handling of alternate+Atom is triggered on a literal value for the 'type' attribute: # If the 'alternate' keyword is used with the 'type' attribute set to the value # 'application/rss+xml' or the value 'application/atom+xml', then the user # agent must treat the link as it would if it had the 'feed' keyword specified # as well. That means rel=feed won't be implied on an Atom Entry document whether the new MIME type syntax is chosen to be application/atom.entry+xml or application/atom+xml;type=entry It also won't be implied on an Atom feed document if the syntax application/atom+xml;type=feed or application/atom+xml;type=archive is used, as was suggested earlier. This gives us a way to say link rel=alternate href=[..] type=[atom] without implying link rel=alternate feed href=[..] type=[atom] and without dropping the 'type' attribute entirely (which was the other solution pointed out on the whatwg list). ~fantasai
Re: PaceEntryMediatype
Actually, for the form application/atom+xml;type=entry it's more likely that browsers will completely ignore the type param as they do currently. - James fantasai wrote: [snip] That means rel=feed won't be implied on an Atom Entry document whether the new MIME type syntax is chosen to be application/atom.entry+xml or application/atom+xml;type=entry It also won't be implied on an Atom feed document if the syntax application/atom+xml;type=feed or application/atom+xml;type=archive is used, as was suggested earlier. This gives us a way to say link rel=alternate href=[..] type=[atom] without implying link rel=alternate feed href=[..] type=[atom] and without dropping the 'type' attribute entirely (which was the other solution pointed out on the whatwg list). ~fantasai
Re: PaceEntryMediatype
Thomas Broyer wrote: 2006/11/29, James M Snell: Create a new media type for Atom Entry Documents: application/atomentry+xml Deprecate the use of application/atom+xml for Entry Documents. I'd largely prefer augmenting the existing media type with a 'type' parameter: - application/atom+xml = either feed or entry (as defined in RFC4287) - application/atom+xml;type=feed = feed - application/atom+xml;type=entry = entry I also think this is a nicer solution. It reflects that the two document types are fundamentally the same format. If there's no practical reason to have two actually separate MIME types, I think it would make more sense to differentiate entry and feed documents like this. ~fantasai
Re: PaceEntryMediatype
James M Snell wrote: Actually, for the form application/atom+xml;type=entry it's more likely that browsers will completely ignore the type param as they do currently. Well, if a browser ignores a media type's parameters, it will have to face the consequences: In the case of application/atom+xml;type=entry it would get application/atom+xml which means 'either an Atom Feed or Entry Document'; if it cannot handle Atom Entry Documents without breaking, it does not properly implement RFC 4287. But your point that *current* browsers silent discard a type parameter on application/atom+xml is moot anyway since the *current* Atom RFC specifies no such parameter. That being said, an *optional* type parameter offers the cleanest solution to distinguishing between the following three cases: 1) Either an Atom Feed or Entry Document 2) An Atom Feed Document 3) An Atom Entry Document If RFC 4287 had defined separate media types for the latter two cases, we wouldn't have this problem, of course: Accept: application/atomfeed+xml, application/atomentry+xml would cover the first case just fine. But since the RFC sadly doesn't I am extremely reluctant to either deprecating the use of application/atom+xml for Atom Entry Documents or to introducing three media types overall when an optional parameter suffices. So, James, what is wrong with application/atom+xml;type=[entry|feed]? (A slim majority on this list seems to prefer it over defining separate media types.) Regards, Andreas Sewe
Re: PaceEntryMediatype
I feel like this whole discussion about whether an entry is logically equivalent to a feed is a little bit of a red herring. To me, the important justification for forking the Atom content type comes from a belief that this is useful information that you need *before* you retrieve/process the target document. I think we can all agree that parsing/syntax alone isn't enough to justify this; there are many existing Atom parsing impls that can handle the current approach just fine, and lots of counter examples of other MIME types that do even more overloading of multiple semantic content types under a single syntactic content type (ex text/xml). Something which can't handle the current range of potential Atom document contents for application/atom+xml doesn't seem like a strong argument either. We all know it's _possible_, it's just that in some contexts (like feed reading) it hasn't been considered _interesting_ to implement entry handling. I don't think a new MIME type fixes this, there are lots of real world cases of software developers who only implement a subset of a spec that they find is interesting or useful, it's always gonna happen but often gets fixed. I'm still looking for one or two use cases where having the distinction between whether a referenced document points to a feed or an entry is a vital thing. I can honestly say from the GData side we haven't seen this need yet, but that doesn't mean it exists. A link relation mght imply the content type (ex 'subscribe') or might be a logical relation that can apply to multiple content-types (as Lisa noted), but in the latter case what benefits do feed vs. entry doc distinction buy you? -- Kyle On 12/6/06, Andreas Sewe [EMAIL PROTECTED] wrote: James M Snell wrote: Actually, for the form application/atom+xml;type=entry it's more likely that browsers will completely ignore the type param as they do currently. Well, if a browser ignores a media type's parameters, it will have to face the consequences: In the case of application/atom+xml;type=entry it would get application/atom+xml which means 'either an Atom Feed or Entry Document'; if it cannot handle Atom Entry Documents without breaking, it does not properly implement RFC 4287. But your point that *current* browsers silent discard a type parameter on application/atom+xml is moot anyway since the *current* Atom RFC specifies no such parameter. That being said, an *optional* type parameter offers the cleanest solution to distinguishing between the following three cases: 1) Either an Atom Feed or Entry Document 2) An Atom Feed Document 3) An Atom Entry Document If RFC 4287 had defined separate media types for the latter two cases, we wouldn't have this problem, of course: Accept: application/atomfeed+xml, application/atomentry+xml would cover the first case just fine. But since the RFC sadly doesn't I am extremely reluctant to either deprecating the use of application/atom+xml for Atom Entry Documents or to introducing three media types overall when an optional parameter suffices. So, James, what is wrong with application/atom+xml;type=[entry|feed]? (A slim majority on this list seems to prefer it over defining separate media types.) Regards, Andreas Sewe
Re: PaceEntryMediatype
Mark Baker wrote: Isn't that just a case of people not implementing the whole spec though? Not really. The RFC defines the structure, not so much the interaction model around feeds (which is driven by UIs more than anything else, so I can buy into it being somewhat arbitrary) Or, are there applications which only process entry documents and not feed documents? Anything based on Atom Protocol will be making a distinction. cheers Bill
Re: PaceEntryMediatype
The key problem I have with the ;type=param is that it's optional and likely to be ignored by a good number of implementations (which ends up buying us nothing in terms of interop). A separate media type is less ideal but has greater practical value in that it addresses the problem immediately. - James Andreas Sewe wrote: James M Snell wrote: Actually, for the form application/atom+xml;type=entry it's more likely that browsers will completely ignore the type param as they do currently. Well, if a browser ignores a media type's parameters, it will have to face the consequences: In the case of application/atom+xml;type=entry it would get application/atom+xml which means 'either an Atom Feed or Entry Document'; if it cannot handle Atom Entry Documents without breaking, it does not properly implement RFC 4287. But your point that *current* browsers silent discard a type parameter on application/atom+xml is moot anyway since the *current* Atom RFC specifies no such parameter. That being said, an *optional* type parameter offers the cleanest solution to distinguishing between the following three cases: 1) Either an Atom Feed or Entry Document 2) An Atom Feed Document 3) An Atom Entry Document If RFC 4287 had defined separate media types for the latter two cases, we wouldn't have this problem, of course: Accept: application/atomfeed+xml, application/atomentry+xml would cover the first case just fine. But since the RFC sadly doesn't I am extremely reluctant to either deprecating the use of application/atom+xml for Atom Entry Documents or to introducing three media types overall when an optional parameter suffices. So, James, what is wrong with application/atom+xml;type=[entry|feed]? (A slim majority on this list seems to prefer it over defining separate media types.) Regards, Andreas Sewe
Re: PaceEntryMediatype
James M Snell wrote: The key problem I have with the ;type=param is that it's optional and likely to be ignored by a good number of implementations (which ends up buying us nothing in terms of interop). A separate media type is less ideal but has greater practical value in that it addresses the problem immediately. Understood. I don't think, however, that a separate media type for Entry Documents will solve more problems than it causes: Applications which adhere to RFC 4287 and accept both Feed and Entry Documents labeled as application/atom+xml won't recognize application/atomentry+xml; they will have to be updated. But, honestly, I would rather see those buggy applications updated which break whenever they encounter an Entry Document labeled correctly as application/atom+xml. That's a bug waiting to be fixed anyway, whether we immediately deprecate the labeling of Entry Documents application/atom+xml or not; some Entry Documents have already escaped into the wild. Regards, Andreas Sewe
Re: PaceEntryMediatype
On Wed, 06 Dec 2006 05:22:24 +0100, Mark Baker [EMAIL PROTECTED] wrote: It wasn't the most illustrative choice of words, but what I'm looking for is evidence that an entry is interpreted differently if it's found in an entry document, than if it were found in a feed document. If we turn up multiple interoperable examples of that, then a new media type is warranted because it's really two formats masquerading as one. To turn it a bit around: Would you ever want to subscribe to a single Atom Entry? If not, wouldn't it be good to know that it was an Atom Entry and not an Atom Feed before you started subscribing to it? -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: PaceEntryMediatype
To turn it a bit around: Would you ever want to subscribe to a single Atom Entry? If not, wouldn't it be good to know that it was an Atom Entry and not an Atom Feed before you started subscribing to it? This is misleading wording (and maybe part of the overall problem)! Following a link is not the same thing as subscribing to something. The act of subscribing is a local activity performed by the user agent. What you do when you follow the link to a feed is a GET. Your agent then decides if subscribing to that resource is a good idea. To make that decision, the agent has to look at the representation and the it is insignificant overhead to see if the thing returnes feed or entry. Anyhow, why not monitor a single entry? I think this is far more a user agent configuration issue than it is a problem of the media type being returned. FWIW, I think the question of media type (or the feed-ness of some resource) and the issue of whether to subscribe or not are completely orthogonal. Maybe I want to monitor a single media resource; an Atom media entry would be an ideal thing to do so (I'd rather look at the meta data than at the media resource upon each poll). I'd say: stick with the one media type that is currently there - there is no problem, just misconception about what it means to subscribe. Jan
Re: PaceEntryMediatype
On Dec 6, 2006, at 12:14 PM, Jan Algermissen wrote: Following a link is not the same thing as subscribing to something. The act of subscribing is a local activity performed by the user agent. What you do when you follow the link to a feed is a GET. Your agent then decides if subscribing to that resource is a good idea. To make that decision, the agent has to look at the representation and the it is insignificant overhead to see if the thing returnes feed or entry. ... Maybe I want to monitor a single media resource; an Atom media entry would be an ideal thing to do so (I'd rather look at the meta data than at the media resource upon each poll). I'd say: stick with the one media type that is currently there - there is no problem, just misconception about what it means to subscribe. A few reasons why a user agent might want to be able to tell the difference between a link to a feed and a link to an entry beforehand is in order to: 1) be able to ignore the link to the entry (ie. not present it to the user) if the user agent doesn't handle entry documents (rather than presenting it as a subscribe link, only to have to say sorry, it's not a feed after the user tries to subscribe). 2) be able to say subscribe to links to feeds, and monitor links to entries (the user may not be interested in monitoring a single entry for changes--if they can't tell that that's what the link is for, they may end up needlessly doing so but think that they've added another feed to their subscription list).
Re: PaceEntryMediatype
On Wednesday, December 06, 2006, at 08:30PM, Antone Roundy [EMAIL PROTECTED] wrote: On Dec 6, 2006, at 12:14 PM, Jan Algermissen wrote: I'd say: stick with the one media type that is currently there - there is no problem, just misconception about what it means to subscribe. A few reasons why a user agent might want to be able to tell the difference between a link to a feed and a link to an entry beforehand is in order to: But that is an issue of linking semantics, not link target media types. I'd expect the user agent to look for links with 'here is a feed' semantics instead of looking for (arbitrary) links to certain media types. IMHO, there is something going wrong somewhere - and it ain't the media type. Jan 1) be able to ignore the link to the entry (ie. not present it to the user) if the user agent doesn't handle entry documents (rather than presenting it as a subscribe link, only to have to say sorry, it's not a feed after the user tries to subscribe). 2) be able to say subscribe to links to feeds, and monitor links to entries (the user may not be interested in monitoring a single entry for changes--if they can't tell that that's what the link is for, they may end up needlessly doing so but think that they've added another feed to their subscription list).
Re: PaceEntryMediatype
Antone Roundy wrote: On Dec 6, 2006, at 12:14 PM, Jan Algermissen wrote: Following a link is not the same thing as subscribing to something. The act of subscribing is a local activity performed by the user agent. What you do when you follow the link to a feed is a GET. Your agent then decides if subscribing to that resource is a good idea. To make that decision, the agent has to look at the representation and the it is insignificant overhead to see if the thing returnes feed or entry. ... Maybe I want to monitor a single media resource; an Atom media entry would be an ideal thing to do so (I'd rather look at the meta data than at the media resource upon each poll). I'd say: stick with the one media type that is currently there - there is no problem, just misconception about what it means to subscribe. A few reasons why a user agent might want to be able to tell the difference between a link to a feed and a link to an entry beforehand is in order to: 1) be able to ignore the link to the entry (ie. not present it to the user) if the user agent doesn't handle entry documents (rather than presenting it as a subscribe link, only to have to say sorry, it's not a feed after the user tries to subscribe). 2) be able to say subscribe to links to feeds, and monitor links to entries (the user may not be interested in monitoring a single entry for changes--if they can't tell that that's what the link is for, they may end up needlessly doing so but think that they've added another feed to their subscription list). 3) to open an entry in an editing app. Datapoint: double clicking on an Atom Entry file in Ubuntu results in the following: [[[ The filename LE1100_1254262_1_4E760C4E-36D9-065D-7AF7-FB168427888D_1081337005687.xml indicates that this file is of type XML document. The contents of the file indicate that the file is of type Draft journal entry. If you open this file, the file might present a security risk to your system. Do not open the file unless you created the file yourself, or received the file from a trusted source. To open the file, rename the file to the correct extension for Draft journal entry, then open the file normally. Alternatively, use the Open With menu to choose a specific application for the file. ]]] I believe this is because I had drivel installed at one point. Double clicking on an Atom Feed document opens it in Firefox. I'm kind of surprised by this, but thinking about it, you don't really write feeds, but you do write entries. cheers Bill
Re: PaceEntryMediatype
Andreas Sewe wrote: [snip] Applications which adhere to RFC 4287 and accept both Feed and Entry Documents labeled as application/atom+xml won't recognize application/atomentry+xml; they will have to be updated. In consider that a feature. - James
Re: PaceEntryMediatype
On Wed, 06 Dec 2006 19:14:04 +0100, Jan Algermissen [EMAIL PROTECTED] wrote: This is misleading wording (and maybe part of the overall problem)! Perhaps, but it describes one of the most important use-cases with feeds -- which won't be the one with entries. Following a link is not the same thing as subscribing to something. Of course not. The act of subscribing is a local activity performed by the user agent. What you do when you follow the link to a feed is a GET. Yep. But why would you do the GET in the first place? In what use case scenario would you put GET-ing an URI that returns an Atom Entry compared to one that returns an Atom Feed? Your agent then decides if subscribing to that resource is a good idea. How does it decide? By parsing the whole document first, e.g. content sniffing? To make that decision, the agent has to look at the representation and the it is insignificant overhead to see if the thing returnes feed or entry. Not if the resource needn't be GET in the first place. If the whole operation can be decided upon the Content-Type returned in a HEAD request, or even better; by the value in the @type attribute of whatever element referring to this resource, the client won't have to do a GET at all on resources it doesn't know how to handle properly. Most feed readers knows how to handle feeds, but have no idea how to handle entries. When pointed at a URI they can say Hey, I can't subscribe to this! if the Content-Type is 'text/html', 'application/octet-stream' or whatever, but if the Content-Type is 'application/atom+xml', they think Hey, this is a feed I can subscribe to! and will in most cases fail because what they're trying to subscribe to isn't an Atom Feed but an Atom Entry. Knowing before the GET whether the resource can be subscribed to (or whatever you may want to do with either entries or feeds separately) or not is useful information. And please note that subscribe is used here as a single use-case for the endless amounts of use-cases that will differ for Atom Feeds and Atom Entries. Anyhow, why not monitor a single entry? That's of course possible, but you will be monitoring indirectly if you're subscribing to a feed that has that entry and changes to that entry gets re-published to the same feed. However, that's not the issue at hand here. I think this is far more a user agent configuration issue than it is a problem of the media type being returned. I disagree. FWIW, I think the question of media type (or the feed-ness of some resource) and the issue of whether to subscribe or not are completely orthogonal. They are and they aren't. -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: PaceEntryMediatype
Jan Algermissen wrote: [snip] So they should be fixed, should they not? They seem to only have implemented half a media type. The half they're interested in. Why aren't they interested in the other half? - James
Re: PaceEntryMediatype
On Dec 6, 2006, at 11:01 PM, Asbjørn Ulsberg wrote: On Wed, 06 Dec 2006 19:14:04 +0100, Jan Algermissen [EMAIL PROTECTED] wrote: This is misleading wording (and maybe part of the overall problem)! Perhaps, but it describes one of the most important use-cases with feeds -- which won't be the one with entries. Sorry, I do not understand what you mean. Following a link is not the same thing as subscribing to something. Of course not. The act of subscribing is a local activity performed by the user agent. What you do when you follow the link to a feed is a GET. Yep. But why would you do the GET in the first place? In what use case scenario would you put GET-ing an URI that returns an Atom Entry compared to one that returns an Atom Feed? Again, sorry, I am unable to see what you are trying to tell me. Can you explain? Your agent then decides if subscribing to that resource is a good idea. How does it decide? By parsing the whole document first, e.g. content sniffing? Not sniffing, but parsing. This would be done anyhow, no? You get back a doc element object, look at the name of the root elemet and dispatch. To make that decision, the agent has to look at the representation and the it is insignificant overhead to see if the thing returnes feed or entry. Not if the resource needn't be GET in the first place. If the whole operation can be decided upon the Content-Type returned in a HEAD request, or Ok, HEAD would save the extra payload, butI still think the reason for subscribing is NOT how the representation at the other end looks, it is based on the link semantics. even better; by the value in the @type attribute of whatever element referring to this resource, the client won't have to do a GET at all on resources it doesn't know how to handle properly. This would be against Web arch: Content-Type is authoritative and can well overide whatever the type attribute says or said a year ago. Most feed readers knows how to handle feeds, but have no idea how to handle entries. So they should be fixed, should they not? They seem to only have implemented half a media type. When pointed at a URI they can say Hey, I can't subscribe to this! What about chaging that to have them open a 'select plugin for this media type' dialog? How come the desire for making the user agent rely on a certain, rather limited circumstance (getting a feed). Shouldn't Web agents be more actively-trying? if the Content-Type is 'text/html', 'application/octet-stream' or whatever, but if the Content-Type is 'application/atom+xml', they think Hey, this is a feed I can subscribe to! Then they implemented the RFC incorrectly I'd say. and will in most cases fail because what they're trying to subscribe to isn't an Atom Feed but an Atom Entry. Again, why be so defensive? If your browser behaved like that you'd kick it out (I'd do so at least). Knowing before the GET whether the resource can be subscribed to (or whatever you may want to do with either entries or feeds separately) or not is useful information. Ok, but it is simply not authoritative. And please note that subscribe is used here as a single use-case for the endless amounts of use-cases that will differ for Atom Feeds and Atom Entries. That is one of the concerns I have: subscribing is just *one* use case...and not even an Atom specific one. Anyhow, why not monitor a single entry? That's of course possible, but you will be monitoring indirectly if you're subscribing to a feed that has that entry and changes to that entry gets re-published to the same feed. However, that's not the issue at hand here. I think this is far more a user agent configuration issue than it is a problem of the media type being returned. I disagree. FWIW, I think the question of media type (or the feed-ness of some resource) and the issue of whether to subscribe or not are completely orthogonal. They are and they aren't. Then, in what sense are they not orthogonal??? [good discusion anyhow :-)] Jan -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: PaceEntryMediatype
On Dec 6, 2006, at 11:30 PM, James M Snell wrote: Jan Algermissen wrote: [snip] So they should be fixed, should they not? They seem to only have implemented half a media type. The half they're interested in. Why aren't they interested in the other half? Ha! Forget about the media type - let's drop entry documents. Jan - James
Re: PaceEntryMediatype
I certainly hope you're kidding about dropping entry docs. Let's just label 'em differently and move on. - James Jan Algermissen wrote: On Dec 6, 2006, at 11:30 PM, James M Snell wrote: Jan Algermissen wrote: [snip] So they should be fixed, should they not? They seem to only have implemented half a media type. The half they're interested in. Why aren't they interested in the other half? Ha! Forget about the media type - let's drop entry documents. Jan - James
Re: PaceEntryMediatype
On Dec 6, 2006, at 4:26 PM, Jan Algermissen wrote: Most feed readers knows how to handle feeds, but have no idea how to handle entries. So they should be fixed, should they not? If the purpose of a feed reader is to subscribe to feeds and bring new and updated entries to the user's attention, then if they don't also handle the monitoring of single entry documents (interesting to some people in some cases, but I doubt interesting to most people), that's not necessarily something that needs fixing. They seem to only have implemented half a media type. ...or they've implemented all of what should be covered by one media type.
Re: PaceEntryMediatype
* Jan Algermissen [EMAIL PROTECTED] [2006-12-06 20:55]: But that is an issue of linking semantics, not link target media types. I'd expect the user agent to look for links with 'here is a feed' semantics instead of looking for (arbitrary) links to certain media types. IMHO, there is something going wrong somewhere - and it ain't the media type. It seems pointless for atom:link to have a type attribute at all then. You should be able to decide anything you need to decide by GETting the resource (and sometimes parsing it). Why did we add such a useless feature to the spec? Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: PaceEntryMediatype
On Dec 7, 2006, at 7:43 AM, A. Pagaltzis wrote: It seems pointless for atom:link to have a type attribute at all then. You should be able to decide anything you need to decide by GETting the resource (and sometimes parsing it). Why did we add such a useless feature to the spec? I am pretty sure it wasn't added for being able to tell people: Look, at the other end of this link is a feed. 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? As an analogy: HTML browsers look for stylesheets where it says link rel=stylesheet type=text/css href=/style.css / and not link rel=alternate type=text/css href=/style.css / Eh? Jan Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: PaceEntryMediatype
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 entries, dropping them is not too farfetched, is it? Let's just label 'em differently and move on. I still do not see the use cases justifying a new media type - it might be the right thing to do but for the time being it looks like a workaround. Jan - James Jan Algermissen wrote: On Dec 6, 2006, at 11:30 PM, James M Snell wrote: Jan Algermissen wrote: [snip] So they should be fixed, should they not? They seem to only have implemented half a media type. The half they're interested in. Why aren't they interested in the other half? Ha! Forget about the media type - let's drop entry documents. Jan - James
Re: PaceEntryMediatype
On Dec 4, 2006, at 10:12 PM, Mark Baker wrote: On 12/4/06, James M Snell [EMAIL PROTECTED] wrote: All I can go on is evidence of how folks are actually using 'em... and they ain't using 'em as aliases. :-) Ok, I'll take empirical evidence too 8-) Point the way ... Question: what does it mean (what do we have to look for) to use them as aliases?? Jan Mark.
Re: PaceEntryMediatype
When I process this entry, http://www.google.com/calendar/feeds/jasnell%40gmail.com/public/basic/10ge5k2k7c488algfbau5q9qc0 What is the implied feed? Where do I get the implied feeds metadata? Title? ID? Anything? If the entry contained an atom:source element you might be able to assume that a logical feed is implied but absent any other evidence, this is a standalone entry document that can be processed without any assumption that a feed exists. - James Mark Baker wrote: On 12/4/06, James M Snell [EMAIL PROTECTED] wrote: All I can go on is evidence of how folks are actually using 'em... and they ain't using 'em as aliases. :-) Ok, I'll take empirical evidence too 8-) Point the way ... Mark.
Re: PaceEntryMediatype
On Dec 5, 2006, at 9:15 PM, James M Snell wrote: When I process this entry, http://www.google.com/calendar/feeds/jasnell%40gmail.com/public/ basic/10ge5k2k7c488algfbau5q9qc0 Funny, Safari switches to feed://www.google.com :-) And then says it cannot process the entity (presumably because it is an entry). Jan
Re: PaceEntryMediatype
Mark Baker wrote: On 12/4/06, James M Snell [EMAIL PROTECTED] wrote: All I can go on is evidence of how folks are actually using 'em... and they ain't using 'em as aliases. :-) Ok, I'll take empirical evidence too 8-) Point the way ... Mark, since you introduced it, what's an alias, exactly? cheers Bill
Re: PaceEntryMediatype
James M Snell wrote: When I process this entry, http://www.google.com/calendar/feeds/jasnell%40gmail.com/public/basic/10ge5k2k7c488algfbau5q9qc0 I had problems subscribing to that entry in bloglines. Will somebody file a bug? cheers Bill
Re: PaceEntryMediatype
Indeed. The application was written to expect a feed because of the content-type but gets an entry instead and blows up. - James Jan Algermissen wrote: On Dec 5, 2006, at 9:15 PM, James M Snell wrote: When I process this entry, http://www.google.com/calendar/feeds/jasnell%40gmail.com/public/basic/10ge5k2k7c488algfbau5q9qc0 Funny, Safari switches to feed://www.google.com :-) And then says it cannot process the entity (presumably because it is an entry). Jan
Re: PaceEntryMediatype
On 12/5/06, Jan Algermissen [EMAIL PROTECTED] wrote: Question: what does it mean (what do we have to look for) to use them as aliases?? It wasn't the most illustrative choice of words, but what I'm looking for is evidence that an entry is interpreted differently if it's found in an entry document, than if it were found in a feed document. If we turn up multiple interoperable examples of that, then a new media type is warranted because it's really two formats masquerading as one. Mark.
Re: PaceEntryMediatype
On 12/5/06, James M Snell [EMAIL PROTECTED] wrote: When I process this entry, http://www.google.com/calendar/feeds/jasnell%40gmail.com/public/basic/10ge5k2k7c488algfbau5q9qc0 What is the implied feed? Where do I get the implied feeds metadata? Title? ID? Anything? If the entry contained an atom:source element you might be able to assume that a logical feed is implied but absent any other evidence, this is a standalone entry document that can be processed without any assumption that a feed exists. Ok, but I don't see that this would necessitate a new media type. 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? Sorry if I wasn't clear what I was looking for earlier by my use of the word alias. Mark.
Re: PaceEntryMediatype
Mark Baker wrote: [snip] Ok, but I don't see that this would necessitate a new media type. 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. Sure, it might be the same parser code, but not necessarily the same bit of code using the parser. Look at the way Firefox, IE7, Bloglines, Liferea, etc all handle (or don't handle) Entry documents versus Feed documents. The majority of applications that most frequently handle Atom Feed Documents have no idea how to deal with Atom Entry Documents and I would wager that most applications that understand how to process Atom Entry Documents and Atom Feed Documents typically don't fall into the same category as most feed readers. - James
Re: PaceEntryMediatype
On 6/12/06 3:52 PM, James M Snell [EMAIL PROTECTED] wrote: Not necessarily. Sure, it might be the same parser code, but not necessarily the same bit of code using the parser. Look at the way Firefox, IE7, Bloglines, Liferea, etc all handle (or don't handle) Entry documents versus Feed documents. The majority of applications that most frequently handle Atom Feed Documents have no idea how to deal with Atom Entry Documents and I would wager that most applications that understand how to process Atom Entry Documents and Atom Feed Documents typically don't fall into the same category as most feed readers. If an agent found an entry document, should it assume that it's a feed with one entry (so far) and allocate resources accordingly (ie. allow for cardinality of n++)? If an agent found an entry document, and then later returned to find a feed containing multiple entries, would it consider that a problem? Would an agent finding multiple atom:content elements inside the one entry consider that a problem (other than it being a spec violation)? Are XML processors optimised for the fact that any given attribute can only occur once per element, and not twice or more .. eg. foo attr=1 attr=2 / ? e.
Re: PaceEntryMediatype
On 12/5/06, James M Snell [EMAIL PROTECTED] wrote: Mark Baker wrote: [snip] Ok, but I don't see that this would necessitate a new media type. 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. Sure, it might be the same parser code, but not necessarily the same bit of code using the parser. Look at the way Firefox, IE7, Bloglines, Liferea, etc all handle (or don't handle) Entry documents versus Feed documents. The majority of applications that most frequently handle Atom Feed Documents have no idea how to deal with Atom Entry Documents and I would wager that most applications that understand how to process Atom Entry Documents and Atom Feed Documents typically don't fall into the same category as most feed readers. 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 won't help. Or, are there applications which only process entry documents and not feed documents? Mark.
Re: PaceEntryMediatype
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 won't help. The interesting question is *why* haven't those applications implemented support for Entry Documents. My guess is that Entry documents aren't particularly interesting to their use cases which is likely because they serve a different purpose. Entry documents serve an extremely useful purpose in the Atom Publishing Protocol. They serve a significantly less useful purpose for your typical feed reader. That doesn't make them worthy of deprecation; it just means entry documents are different than feed documents. Or, are there applications which only process entry documents and not feed documents? Wrong question. APP clients process both entry documents and feed documents but do so for entirely different reasons than feed readers. - James
Re: PaceEntryMediatype
Eric Scheid wrote: [snip] If an agent found an entry document, should it assume that it's a feed with one entry (so far) and allocate resources accordingly (ie. allow for cardinality of n++)? No. In particular, if an atom:source element is not included there is no way of knowing anything about the implied feed; no atom:id, no atom:updated, no atom:title, none of the minimal bits of information the atom spec requires for a feed. An implied feed would serve no purpose. If an agent found an entry document, and then later returned to find a feed containing multiple entries, would it consider that a problem? That obviously depends on how the code was written. If it's an APP client that's expecting to edit an Atom entry then, yeah, it'll quite likely be a problem. Now reverse it. If an agent (e.g. firefox) finds a feed document and then later returned to find an entry, would it consider that a problem? Would an agent finding multiple atom:content elements inside the one entry consider that a problem (other than it being a spec violation)? Are XML processors optimised for the fact that any given attribute can only occur once per element, and not twice or more .. eg. foo attr=1 attr=2 / ? Ok, you lost me on these last two. I'm not sure what you're getting at. - James
Re: PaceEntryMediatype
On 6/12/06 5:06 PM, James M Snell [EMAIL PROTECTED] wrote: Would an agent finding multiple atom:content elements inside the one entry consider that a problem (other than it being a spec violation)? Are XML processors optimised for the fact that any given attribute can only occur once per element, and not twice or more .. eg. foo attr=1 attr=2 / ? Ok, you lost me on these last two. I'm not sure what you're getting at. It's just the cardinality question in a different context. Argument by analogy. e.
Re: PaceEntryMediatype
On 12/5/06, James M Snell [EMAIL PROTECTED] wrote: Mark Baker wrote: [snip] Ok, but I don't see that this would necessitate a new media type. 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. Sure, it might be the same parser code, but not necessarily the same bit of code using the parser. Look at the way Firefox, IE7, Bloglines, Liferea, etc all handle (or don't handle) Entry documents versus Feed documents. The majority of applications that most frequently handle Atom Feed Documents have no idea how to deal with Atom Entry Documents and I would wager that most applications that understand how to process Atom Entry Documents and Atom Feed Documents typically don't fall into the same category as most feed readers. 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 won't help. Or, are there applications which only process entry documents and not feed documents? Mark. Mark, Since the beginning you seem to solely focus on what feed readers do or don't do. Suggesting deprecating the entry document on the APP list is quite missing the point really. If people keep seeing Atom as a RSS alternative then there is a big communication failure from the Atom folks. Atom feeds are actually less worthy than Atom entries which should have been pushed even harder as the first class citizen within the RFC. The Atom entry element is the one carrying the information and is the one that needs a media-type on its own, or at least a way to mint that media-type to make it clear to UAs what they're dealing with. In fact I will be really interested to hearing from folks who write APP client extensions for Firefox, Opera or else. Certainly they will tell us that they don't care about Atom feeds as much as they do about Atom entries. The thing is that adding a new media-type now would not impact thoroughly current implementations if for instance we were to say that application/atom+xml is for Atom feed and application/atomentry+xml was newly introduced for Atom entry. I actually do not understand why people get so reluctant at it. - Sylvain
Re: PaceEntryMediatype
And therein lies the problem: entry documents are NOT aliases for single-entry feeds. - James Mark Baker wrote: [snip] True, but if entry documents are more or less aliases for single-entry feeds, why would anybody need to negotiate for one or the other? I suggest that would have to be pretty obscure use case. 8-) Mark.
Re: PaceEntryMediatype
I'd be happy to believe you James, if I could find where in the spec that was stated. If it looks like an alias, and acts like an alias ... 8-) Mark. On 12/4/06, James M Snell [EMAIL PROTECTED] wrote: And therein lies the problem: entry documents are NOT aliases for single-entry feeds. - James Mark Baker wrote: [snip] True, but if entry documents are more or less aliases for single-entry feeds, why would anybody need to negotiate for one or the other? I suggest that would have to be pretty obscure use case. 8-) Mark.
Re: PaceEntryMediatype
Mark Baker wrote: I'd be happy to believe you James, if I could find where in the spec that was stated. Neither does it state they are a 1-to-1 relationship. If it looks like an alias, and acts like an alias ... 8-) Calling them aliases won't make them necessarily aliases. I find unfortunate that RFC 4287 doesn't actually precise that particular point. We only have one media type and no clear definition of the distinction between an entry element and an entry document. So we have this discussion. - Sylvain
Re: PaceEntryMediatype
On 12/4/06, James M Snell [EMAIL PROTECTED] wrote: All I can go on is evidence of how folks are actually using 'em... and they ain't using 'em as aliases. :-) Ok, I'll take empirical evidence too 8-) Point the way ... Mark.
Re: PaceEntryMediatype
2006/12/2, Antone Roundy: Now that this has sunk in, it makes a lot of sense--the @rel value says you can subscribe to that, Why would I subscribe? is it an alternate representation of what I'm looking at? or the feed containing the article I'm looking at? or a totally distinct resource that might interest me if I'm interested in what I'm looking at (think about blogrolls and the people who bought this also bought that and that links)? By saying you can subscribe to that, you're not describing a relation. Maybe you're describing a facet of the resource the link points to, but is this objective or subjective? If it's meant to be objective, then the media type is enough (am I *able* to subscribe to such a thing), or maybe there's a need for another kind of metadata (I proposed a new 'subscribable' attribute on the WHATWG list). The media type helps the user agent figure out whether it has the capability to do those things. For example, a feed reader that only handles RSS could ignore subscription links to resources of type application/atom+xml (ie. not present the subscription option to the user). And if an UA has the capability to subscribe to something, why couldn't it provide a mean to subscribe, whichever the relationship? What would be important is to reflect the relationship on the UI so the user have all the information available to choose whether he *wants* to subscribe. The subscribe to hAtom feed case where @type is text/ html might be a little difficult to make a decision on, because there's no indication of what microformat is being used by the feed (or even if there's a microformat in use at all--maybe it really is just an HTML page, and subscribing to it just means watch for changes to the entire document). ...or it's an HTML5 page making use of the new article element... One problem that I hadn't really thought clearly about till right now is that understanding the nature of the think linked TO may require some understanding of the nature of the thing linked FROM. For example, an alternate link from a typical blog homepage to its feed really does point to the same thing in an alternative format. Both are live documents in which new data gets added to the top, and old data drops off the bottom. But if you don't know that the webpage is a live document, you wouldn't know whether the link pointed to a static or live document. alternate is perfectly accurate, but it's not helpful enough. subscribe would be much more explicit. Why should it be automated? When you go read a web site every morning because you know it's live, it's not automated. What you could automate is how to go read that site (e.g. use it as your browser's start page, or include it in a bunch of bookmarks you open in tabs every morning). There's not always a need to automate everything. Things like whether it'd be interesting to subscribe to something are better handled by humans than computers. -- Thomas Broyer
Re: PaceEntryMediatype
On Wed, 29 Nov 2006 20:03:22 +0100, Thomas Broyer [EMAIL PROTECTED] wrote: I'd largely prefer augmenting the existing media type with a 'type' parameter: - application/atom+xml = either feed or entry (as defined in RFC4287) - application/atom+xml;type=feed = feed - application/atom+xml;type=entry = entry +1. How about defining a tree similar to the */vnd.* one? - application/atom+xml = feed or entry document - application/atom.categories+xml = category document - application/atom.service+xml = service document ...and of course, if this proposal is finally accepted: - application/atom.entry+xml = entry document I think 'type=*' is a cleaner solution, but both serves the same purpose so I'm not religious about which solution we choose. But I agree that distinguishing between entries, feeds and every other atom resource is indeed useful. +1. As for Tim's concerns, I'd also prefer having it done outside the APP. Yep. Also, the APP draft would need to be updated to remove the entry special value for app:accept, as it would be equivalent to the new or revised media type (app:accept=application/atom+xml;type=entry or app:accept=applicationAtom.entry+xml) Of course. -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: PaceEntryMediatype
On Fri, 01 Dec 2006 19:42:20 +0100, Kyle Marvin [EMAIL PROTECTED] wrote: This points out that the above rel+type don't carry sufficient semantic meaning to help a UA decide what to do with them. I don't think anyone on this thread is disagreeing with that. This discussion (as I understand it) is about what to do given that ambiguity. You can either get more specific with the rel value, with the content-type, or with both. The problem with baking the necessary information for this particular use case inside the 'rel' value is that we possibly need a million different 'rel' values for a million diffierent use cases, or what we'll see is semantic overloading where 'rel' values are abused to mean different things in different use cases and that again will hurt interoperability. Instead, we can let consumers define their own use cases upon the given content type and not push our pre-defined use cases (in the form of 'rel' values) down their throat because we're too reluctant to expand the MIME type of atom with a 'type' attribute (or something similar). Are we confident enough about Atom's entire spectre of use cases to say that different 'rel' values are sufficient? I think not. Give consumers the correct content type of the resource instead, and they can themselves decide what to do with it, on the base of a more general 'rel' value that don't dictate what they can and can't do with it. 'rel' values are not sufficient to solve this issue imo. We need something less fine-grained and more generic. We need to define this at the HTTP level. -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: PaceEntryMediatype
The difference between a collection of entries and a single entry is an important one. Sure, once you get inside the Entry, everything is the same, but knowing ahead of time that you are requesting a single Entry assists in processing. If I'm getting an application/atom.entry+xml I know to use my stylesheet for only a single Entry, whereas when I'm getting an application/atom+xml resource, I know I have a collection containing 1 or more Entries. It's the difference between having a variable, or a list of variables. Imagine a system that uses conneg to give atom representations of a file system. I could request http://www.example.com/db/foo/ and depending on what I put in my accept could determine whether I'm getting back the collection of contents of foo/ or if I'm getting the information on the foo/ folder. There are times when you need to differentiate between the two types when rel= values are not available. I agree with James that there should also be a different rel= value to tell the UA what to do with it, but you still need that different type to signal the difference in what it actually is. Since most UA's out there don't really deal with single atom entries as it is right now, and most parsers will have to accept that they might get back only a single entry from an application/atom+xml and the ones that don't understand how to work with a single Entry will just ignore the application/atom.entry+xml link anyway, the impact isn't all that great to clear up this difference in semantics now and for good. Daniel E. Renfer http://kronkltd.net/ On 12/1/06, Lisa Dusseault [EMAIL PROTECTED] wrote: Supporting data or ideas: Some interesting links, semantically speaking, don't even have a fixed MIME type (or not just one, anyhow). If we wanted to add link relations for photo shares on WebDAV repositories, or personal calendars on CalDAV repositories, you'd want to point to the URL to the appropriate WebDAV collection, which could return results in HTML (response to GET without any special stuff), XML (response to PROPFIND), or iCalendar (in the CalDAV case). Not sure how to fully convey all of that, but at least not overloading MIME type with semantic meaning helps the situation. Lisa On Dec 1, 2006, at 9:17 AM, Kyle Marvin wrote: I'm still listening to the debate, but Mark's argument resonates with me. It seems like 'content-type' is more about the expected syntax of the resource at the other end of the wire, not it's semantic meaning. I don't see Atom feeds and entries as syntactically different enough to warrant unique media types, there's lots of existing parsers that seem able to navigate this split just fine already. I expect that if you associated a 'rel' value with links that point to application/atom+xml, whether it is expected to be a feed or an entry would probably be part of the 'rel' description and thus not ambiguous at all. I think the discussion started because of the aforementioned issues with the HTML5 link semantics, which is what should probably be fixed. On top of that, the procedural and back compat issues associated with splitting the mime type now just don't seem to make it a win to me. Crazy busy and largely silent, but not completely awol, -- Kyle On 12/1/06, Mark Baker [EMAIL PROTECTED] wrote: Urgh, sorry for my tardiness; I'm falling behind on my reading. On 11/30/06, Thomas Broyer [EMAIL PROTECTED] wrote: I'd prefer basing autodiscovery on the media types and not at all on the relationships. All a media type tells you (non-authoritatively too) is the spec you need to interpret the document at the other end of the link. That has very little to do with the reasons that you might want to follow the link, subscribe to it, etc.. Which is why you need a mechanism independent from the media type. Like link types. Consider hAtom. If you went by media types alone, you'd be confronted with; link type=text/html href= hatom.html / Not particularly useful for subscription (or anything else for that matter) is it? This would be better; link rel=feed type=text/html href=hatom.html / Autodiscovery should ideally be based primarily on link types, and only secondarily - as an optimization - on media types. Even this should work; link rel=feed href= hatom.html / Mark.
Re: PaceEntryMediatype
Daniel E. Renfer wrote: The difference between a collection of entries and a single entry is an important one. Sure, once you get inside the Entry, everything is the same, but knowing ahead of time that you are requesting a single Entry assists in processing. If I'm getting an application/atom.entry+xml I know to use my stylesheet for only a single Entry, whereas when I'm getting an application/atom+xml resource, I know I have a collection containing 1 or more Entries. It's the difference between having a variable, or a list of variables. Imagine a system that uses conneg to give atom representations of a file system. I could request http://www.example.com/db/foo/ and depending on what I put in my accept could determine whether I'm getting back the collection of contents of foo/ or if I'm getting the information on the foo/ folder. There are times when you need to differentiate between the two types when rel= values are not available. I agree with James that there should also be a different rel= value to tell the UA what to do with it, but you still need that different type to signal the difference in what it actually is. Since most UA's out there don't really deal with single atom entries as it is right now, and most parsers will have to accept that they might get back only a single entry from an application/atom+xml and the ones that don't understand how to work with a single Entry will just ignore the application/atom.entry+xml link anyway, the impact isn't all that great to clear up this difference in semantics now and for good. Daniel E. Renfer http://kronkltd.net/ I wholeheartedly agree with you here. The problem is that so far most of the discussion has been carried from the client side of things without trying to understand the limit of the server side. There are cases where not having a specific media type (or at least a way within the media type to distinguish them) will be a problem. Maybe the impact of those issues is not worth the trouble but if application/atom+xml leads us to the same situation of the unusable application/xml media type then I predict quite mess. My issue here is that most of the discussion has been centered around how an Atom document was consumed until now. With the versatility of Atom and the power of APP it is more than likely that new use of those formats will show up. They may or may not benefit from having several media types. But they will certainly not be hurt by having the choice. Therefore I do believe a new media type should be brought up. - Sylvain
Re: PaceEntryMediatype
Maybe this perspective helps: Is there any other media type that covers more than one document type (root element in the case of XML, but could also be non-XML mime types)? It would be interesting to see how those (if any) deal with the issue. An example would maybe be iCalendar, Ithink. Also: If feeds and entries get their own media types, then a feed (consisting essentially of a bunch of entry documents comes pretty close to a multipart/related message - which would make the very existence of the feed media type questionable. And another thought: HTML has in a sense also two processing models within a single mime type (normal body and frames) and does not have a substantial problem with that, does it? Jan
Re: PaceEntryMediatype
Jan Algermissen wrote: [snip] Is there any other media type that covers more than one document type (root element in the case of XML, but could also be non-XML mime types)? application/xml It would be interesting to see how those (if any) deal with the issue. An example would maybe be iCalendar, Ithink. application/xhtml+xml application/atom+xml ... Also: If feeds and entries get their own media types, then a feed (consisting essentially of a bunch of entry documents comes pretty close to a multipart/related message - which would make the very existence of the feed media type questionable. -1. And another thought: HTML has in a sense also two processing models within a single mime type (normal body and frames) and does not have a substantial problem with that, does it? Different issue. Frames and body are both used by the same types of clients for the same purpose (rendering a UI). They just lead to different results. - James
Re: PaceEntryMediatype
On 12/2/06, Daniel E. Renfer [EMAIL PROTECTED] wrote: The difference between a collection of entries and a single entry is an important one. Sure, once you get inside the Entry, everything is the same, but knowing ahead of time that you are requesting a single Entry assists in processing. But then you're talking about a different resource than the feed, and so should use a different URI than the feed URI. Mark.
Re: PaceEntryMediatype
Urgh, sorry for my tardiness; I'm falling behind on my reading. On 11/30/06, Thomas Broyer [EMAIL PROTECTED] wrote: I'd prefer basing autodiscovery on the media types and not at all on the relationships. All a media type tells you (non-authoritatively too) is the spec you need to interpret the document at the other end of the link. That has very little to do with the reasons that you might want to follow the link, subscribe to it, etc.. Which is why you need a mechanism independent from the media type. Like link types. Consider hAtom. If you went by media types alone, you'd be confronted with; link type=text/html href=hatom.html / Not particularly useful for subscription (or anything else for that matter) is it? This would be better; link rel=feed type=text/html href=hatom.html / Autodiscovery should ideally be based primarily on link types, and only secondarily - as an optimization - on media types. Even this should work; link rel=feed href=hatom.html / Mark.
Re: PaceEntryMediatype
I'm still listening to the debate, but Mark's argument resonates with me. It seems like 'content-type' is more about the expected syntax of the resource at the other end of the wire, not it's semantic meaning. I don't see Atom feeds and entries as syntactically different enough to warrant unique media types, there's lots of existing parsers that seem able to navigate this split just fine already. I expect that if you associated a 'rel' value with links that point to application/atom+xml, whether it is expected to be a feed or an entry would probably be part of the 'rel' description and thus not ambiguous at all. I think the discussion started because of the aforementioned issues with the HTML5 link semantics, which is what should probably be fixed. On top of that, the procedural and back compat issues associated with splitting the mime type now just don't seem to make it a win to me. Crazy busy and largely silent, but not completely awol, -- Kyle On 12/1/06, Mark Baker [EMAIL PROTECTED] wrote: Urgh, sorry for my tardiness; I'm falling behind on my reading. On 11/30/06, Thomas Broyer [EMAIL PROTECTED] wrote: I'd prefer basing autodiscovery on the media types and not at all on the relationships. All a media type tells you (non-authoritatively too) is the spec you need to interpret the document at the other end of the link. That has very little to do with the reasons that you might want to follow the link, subscribe to it, etc.. Which is why you need a mechanism independent from the media type. Like link types. Consider hAtom. If you went by media types alone, you'd be confronted with; link type=text/html href=hatom.html / Not particularly useful for subscription (or anything else for that matter) is it? This would be better; link rel=feed type=text/html href=hatom.html / Autodiscovery should ideally be based primarily on link types, and only secondarily - as an optimization - on media types. Even this should work; link rel=feed href=hatom.html / Mark.
Re: PaceEntryMediatype
Kyle Marvin wrote: [snip] I expect that if you associated a 'rel' value with links that point to application/atom+xml, whether it is expected to be a feed or an entry would probably be part of the 'rel' description and thus not ambiguous at all. I think the discussion started because of the aforementioned issues with the HTML5 link semantics, which is what should probably be fixed. Not necessarily. Consider: link rel=alternate type=application/atom+xml href=feed.xml / link rel=alternate type=application/atom+xml href=archive.xml / link rel=alternate type=application/atom+xml href=entry.xml / What is the purpose of using alternate links? What is a UA supposed to do with 'em? Why did I as a content publisher choose to use the alternate link relation? Are all of these links of equal value to all UA's? Are they all expected to be processed in the same basic way? Should an archive feed be treated the same way as a subscription feed? Consider this use case: In IBM's Activities implementation, each of our Activity collections are entries in a top level master collection. Every Activity has several representations: An Atom entry, An Atom feed, A RSS feed, A HTML page, etc. On the html page I want to be able to link to each of the various representations as alternates. I also want folks to be able to subscribe to the Atom feed and allow the folks who are building APP-enabled editing tools to autodiscover the edit uri of the entry. I don't want UIs to show a subscription link to the Atom entry representation. What I want is something like this: link rel=alternate subscribe type=application/atom+xml href=feed.xml / link rel=alternate edit type=application/atom.entry+xml href=entry.xml / link rel=alternate subsribe type=application/rss+xml href=rss.xml / Given these links I have all of the information I need: * There are three alternate representations: An Atom Entry, An Atom Feed and an RSS Feed. * There are two links I can subscribe to: An Atom Feed and an RSS Feed * There is one edit link Note that this clearly separates the purpose of the link (rel) from the resource type. I don't care what the value of the type attribute is, if rel includes the keyword subscribe (or feed, doesn't matter) then I know I can subscribe to that resource. If the rel contains the keyword alternate I know it's an alternate representation, no other semantics are implied. Each of the keywords in the rel attribute are completely orthogonal to one another. Note also that there is a clear separation between the Atom Feed and Entry types. These are different document types intended for different audiences and deserve different media types. - James
Re: PaceEntryMediatype
On 12/1/06, James M Snell [EMAIL PROTECTED] wrote: Kyle Marvin wrote: [snip] I expect that if you associated a 'rel' value with links that point to application/atom+xml, whether it is expected to be a feed or an entry would probably be part of the 'rel' description and thus not ambiguous at all. I think the discussion started because of the aforementioned issues with the HTML5 link semantics, which is what should probably be fixed. Not necessarily. Consider: link rel=alternate type=application/atom+xml href=feed.xml / link rel=alternate type=application/atom+xml href=archive.xml / link rel=alternate type=application/atom+xml href=entry.xml / What is the purpose of using alternate links? What is a UA supposed to do with 'em? Why did I as a content publisher choose to use the alternate link relation? Are all of these links of equal value to all UA's? Are they all expected to be processed in the same basic way? Should an archive feed be treated the same way as a subscription feed? This points out that the above rel+type don't carry sufficient semantic meaning to help a UA decide what to do with them. I don't think anyone on this thread is disagreeing with that. This discussion (as I understand it) is about what to do given that ambiguity. You can either get more specific with the rel value, with the content-type, or with both. Consider this use case: In IBM's Activities implementation, each of our Activity collections are entries in a top level master collection. Every Activity has several representations: An Atom entry, An Atom feed, A RSS feed, A HTML page, etc. On the html page I want to be able to link to each of the various representations as alternates. I also want folks to be able to subscribe to the Atom feed and allow the folks who are building APP-enabled editing tools to autodiscover the edit uri of the entry. I don't want UIs to show a subscription link to the Atom entry representation. What I want is something like this: link rel=alternate subscribe type=application/atom+xml href=feed.xml / link rel=alternate edit type=application/atom.entry+xml href=entry.xml / link rel=alternate subsribe type=application/rss+xml href=rss.xml / Given these links I have all of the information I need: * There are three alternate representations: An Atom Entry, An Atom Feed and an RSS Feed. * There are two links I can subscribe to: An Atom Feed and an RSS Feed * There is one edit link Note that this clearly separates the purpose of the link (rel) from the resource type. I don't care what the value of the type attribute is, if rel includes the keyword subscribe (or feed, doesn't matter) then I know I can subscribe to that resource. If the rel contains the keyword alternate I know it's an alternate representation, no other semantics are implied. Each of the keywords in the rel attribute are completely orthogonal to one another. So you've solved the above problem by changing both the rel value and the content-type (in a few cases). I'd propose that changing the rel value (alone) would a sufficient solution. The above rel values provide sufficient information with some implied expectations about feed vs. entry resource and potential usage of the href. The implied nature could be explicit if these rel values were enumerated somewhere (for example, you subscribe to feeds, and you edit entries). Note also that there is a clear separation between the Atom Feed and Entry types. These are different document types intended for different audiences and deserve different media types. I see the separation but I'm still missing a clear justifiication for it. I don't see content-type as having anything to do with the audience. It's about what media format you'd get back if you dereference the href and rel is about how you can interpret/interact with it. I feel like the primary audience for content-type is likely to be used in selecting some type of parser when retrieving the resource. Orthogonal to this, the rel value assigns some semantic meaning to the resource (what does the entry or feed describe) and might also specify what interaction model you might expect via the href (ex. edit implies APP edit semantics on an entry resource). Cheers!
Re: PaceEntryMediatype - rel-type instead
On Dec 1, 2006, at 10:42 AM, Kyle Marvin wrote: I see the separation but I'm still missing a clear justifiication for it. I don't see content-type as having anything to do with the audience. It's about what media format you'd get back if you dereference the href and rel is about how you can interpret/ interact with it. I feel like the primary audience for content- type is likely to be used in selecting some type of parser when retrieving the resource. Orthogonal to this, the rel value assigns some semantic meaning to the resource (what does the entry or feed describe) and might also specify what interaction model you might expect via the href (ex. edit implies APP edit semantics on an entry resource). +1 to what Kyle said -- Ernie P.
Re: PaceEntryMediatype
You're right that the differentiation in the content-type is of less importance but without it there's no way for me to unambiguously indicate that a resource has both an Atom Feed representation and an Atom Entry representation. The best I could do is say This things has two Atom representations. Keep in mind that I want to be able to differentiate the types of alternate representations available without having to look at any of the other rel keywords. - James Kyle Marvin wrote: [snip] I see the separation but I'm still missing a clear justifiication for it. I don't see content-type as having anything to do with the audience. It's about what media format you'd get back if you dereference the href and rel is about how you can interpret/interact with it. I feel like the primary audience for content-type is likely to be used in selecting some type of parser when retrieving the resource. Orthogonal to this, the rel value assigns some semantic meaning to the resource (what does the entry or feed describe) and might also specify what interaction model you might expect via the href (ex. edit implies APP edit semantics on an entry resource). Cheers!
Re: PaceEntryMediatype
Hi James, On Dec 1, 2006, at 11:25 AM, James M Snell wrote: You're right that the differentiation in the content-type is of less importance but without it there's no way for me to unambiguously indicate that a resource has both an Atom Feed representation and an Atom Entry representation. The best I could do is say This things has two Atom representations. Keep in mind that I want to be able to differentiate the types of alternate representations available without having to look at any of the other rel keywords. I understand that this is *what* you want, but I'm still unclear why. From where I sit, Kyle's argument makes sense: keep the syntax in content-type, and the semantics in rel-type. This seems both simpler and more consistent with how the web works today. No? Or is there some overriding reason for ignoring rel-type? -- Ernie P.
Re: PaceEntryMediatype
On 12/1/06, James M Snell [EMAIL PROTECTED] wrote: You're right that the differentiation in the content-type is of less importance but without it there's no way for me to unambiguously indicate that a resource has both an Atom Feed representation and an Atom Entry representation. I can see that it's possible to have two different representations for the same resource (GData does this too) but a key question is whether they have the same relation (semantic meaning/purpose relative to the linking content). In your earlier example, they did not (subscription vs. edit). The best I could do is say This things has two Atom representations. Keep in mind that I want to be able to differentiate the types of alternate representations available without having to look at any of the other rel keywords. Can you explain why you want this? I'm not trying to be relentless I just want to make sure I'm not missing something important while pushing back. -- Kyle
Re: PaceEntryMediatype
I could but after the discussions this week I'm not sure its worth it. Yes, everything can be done using different rel values; the content-type thing is more just an annoyance than anything else. I'll just make sure that I never link my Atom entry documents using alternate (even tho that's what they are). - James Kyle Marvin wrote: [snip] Can you explain why you want this? I'm not trying to be relentless I just want to make sure I'm not missing something important while pushing back. -- Kyle
Re: PaceEntryMediatype
On 12/1/06, Mark Baker [EMAIL PROTECTED] wrote: On 11/30/06, Thomas Broyer [EMAIL PROTECTED] wrote: All a media type tells you (non-authoritatively too) is the spec you need to interpret the document at the other end of the link. That has very little to do with the reasons that you might want to follow the link, subscribe to it, etc.. Which is why you need a mechanism independent from the media type. Like link types. Now that this has sunk in, it makes a lot of sense--the @rel value says you can subscribe to that, that is an alternative representation of this, that is where you'd go to edit this, and so on. The media type helps the user agent figure out whether it has the capability to do those things. For example, a feed reader that only handles RSS could ignore subscription links to resources of type application/atom+xml (ie. not present the subscription option to the user). The subscribe to hAtom feed case where @type is text/ html might be a little difficult to make a decision on, because there's no indication of what microformat is being used by the feed (or even if there's a microformat in use at all--maybe it really is just an HTML page, and subscribing to it just means watch for changes to the entire document). But in the case of bare syndication formats, things should be clear enough. So if it really is possible to do option 5 (new media type for entry documents, and @rel values to solve the rest of the issues), and do it cleanly, then that'd be my first choice. If that's doomed (due to a need to be backwards compatible with existing practice) to be a mess of ambiguities and counter-intuitivities (eg. alternate means subscribe when combined with a syndication type, except when it might really mean alternate because it points to a feed archive document, but anything with feed in it always means subscribe...) then oh my. One problem that I hadn't really thought clearly about till right now is that understanding the nature of the think linked TO may require some understanding of the nature of the thing linked FROM. For example, an alternate link from a typical blog homepage to its feed really does point to the same thing in an alternative format. Both are live documents in which new data gets added to the top, and old data drops off the bottom. But if you don't know that the webpage is a live document, you wouldn't know whether the link pointed to a static or live document. alternate is perfectly accurate, but it's not helpful enough. subscribe would be much more explicit. Which raises the question of how to point to a static alternative representation of the data currently found in the document. alternate WOULD be a good word to use for that except that it's already being used to point to live feeds. An option that would almost surely cause confusion would be to use alternative for static alternative representations. The meaning of static wouldn't exactly be intuitively clear. Maybe something more long-winded like (oh no! hyphenation!) static-alternate would do. Or would static alternate (and alternate static and static foo alternate,etc., or perhaps archive alternate, etc.) be better? For backwards compatibility (at least with UAs that don't expect only one value in @rel), subscribe alternate (and alternate subscribe, etc.) could be used rather than simply subscribe. BTW, am I remembering correctly that feed is being promoted for use the way I'm considering subscribe above? If it's not already in use, I'd thinK subscribe would be much better than feed, because feed could as easily mean archive feed as subscription feed-- it's just not explicit enough. But perhaps this discussion all belongs in a different venue anyway... But before I end, what about the question of a different media type for entry documents? For the APP accept element issue, it sounds like maybe they do. But for autodiscovery, maybe they don't. Perhaps neither @type nor @rel is the place to distinguish, for example, between the edit links for entries, their parent feeds, their per-entry comment feeds, monolithic comment feeds, etc. (A media type for entry documents would only help with one of those). Perhaps that is the domain of @title (title=Edit this entry, etc.) Do UAs really need to know the difference, or do only the users need to know? Would making that information machine readable be worth the pain involved (rel=edit monolithic parent comments???) Okay, that's all I can take for now.
Re: PaceEntryMediatype
* Mark Baker [EMAIL PROTECTED] [2006-11-29 20:10]: An entry document is, AFAICT, little more than shorthand for a feed with one entry, minus the feed-specific metadata. It's processing is a subset of feed processing. If the processing or content model of entry is extended, it applies to both feed documents and entry documents. I disagree. There’s not much of a point in subscribing to an entry document, and APP servers will not accept POSTing feeds in place of entries. [Note: subscribing to an entry document is actually somewhat useful in one sense and might become customary in the future, eg. to track changes to a document. However, that’s still an entirely different use case from subscribing to feed.] Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: PaceEntryMediatype
* James M Snell [EMAIL PROTECTED] [2006-11-29 17:40]: http://www.intertwingly.net/wiki/pie/PaceEntryMediatype +1 * Thomas Broyer [EMAIL PROTECTED] [2006-11-29 20:35]: I'd largely prefer augmenting the existing media type with a 'type' parameter: - application/atom+xml = either feed or entry (as defined in RFC4287) - application/atom+xml;type=feed = feed - application/atom+xml;type=entry = entry -0 How about defining a tree similar to the */vnd.* one? - application/atom+xml = feed or entry document - application/atom.categories+xml = category document - application/atom.service+xml = service document ...and of course, if this proposal is finally accepted: - application/atom.entry+xml = entry document +1 I like this very much; it would put some order in the proliferation of Atom-related MIME types. As for Tim's concerns, I'd also prefer having it done outside the APP. +0 Also, the APP draft would need to be updated to remove the entry special value for app:accept, as it would be equivalent to the new or revised media type (app:accept=application/atom+xml;type=entry or app:accept=applicationAtom.entry+xml) +1 Unification is good. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: PaceEntryMediatype
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
Re: PaceEntryMediatype
On Nov 29, 2006, at 7:22 PM, James M Snell wrote: One such problem occurs in atom:link and atom:content elements. Specifically: atom:link type=application/atom+xml href=a.xml / atom:content type=application/atom+xml src=b.xml / Given no other information I have no way of knowing whether these are references to Feed or Entry documents. And what is the problem with that? Jan - James Mark Baker wrote: -1 - there's nothing special about an entry document - AFAICT (because they're not referenced from the pace), the problems referred to have other causes. I prefer we fix those instead. Mark.
Re: PaceEntryMediatype
Thomas Broyer wrote:
James M Snell wrote:
Create a new media type for Atom Entry Documents:
application/atomentry+xml
Deprecate the use of application/atom+xml for Entry Documents.
-0.5.
Using a type parameter seems like a more elegant solution -- and
achieves the same effect.
I'd largely prefer augmenting the existing media type with a 'type'
parameter:
- application/atom+xml = either feed or entry (as defined in RFC4287)
- application/atom+xml;type=feed = feed
- application/atom+xml;type=entry = entry
+1.
This looks IMHO like a cleaner solution; in particular
application/atom+xml fits in nicely as special (or rather more generic)
case of application/atom+xml;type=(feed|entry).
{{{
Atom Entry Documents are identified with the
application/atomentry+xml media type (See section 15).
}}}
How about defining a tree similar to the */vnd.* one?
- application/atom+xml = feed or entry document
- application/atom.categories+xml = category document
- application/atom.service+xml = service document
...and of course, if this proposal is finally accepted:
- application/atom.entry+xml = entry document
-1. I would not go down this road; the trees were designed for a
different purpose. For (optional) type/profile parameters, however,
there is precedent.
As for Tim's concerns, I'd also prefer having it done outside the APP.
+1. A separate Atom Media Types RFC would be good.
Andreas Sewe
Re: PaceEntryMediatype
James M Snell wrote: Mark Baker wrote: [snip] Yes, but more than that. An entry document is, AFAICT, little more than shorthand for a feed with one entry, minus the feed-specific metadata. It's processing is a subset of feed processing. If the processing or content model of entry is extended, it applies to both feed documents and entry documents. Hmm.. I understand what you're saying but I don't think I agree. In the APP implementations I've put together, Feed and Entry documents generally serve two entirely different purposes and are usually intended for two entirely different audiences. Same here. Feeds are collections; saying that entries are implicit collections is something I don't grasp - it's too abstract. [The only time I've been able to treat feeds and entries uniformly is feeding RSS1.0 into a RDF aware system.] cheers Bill
Re: PaceEntryMediatype
A. Pagaltzis wrote: * Mark Baker [EMAIL PROTECTED] [2006-11-29 20:10]: An entry document is, AFAICT, little more than shorthand for a feed with one entry, minus the feed-specific metadata. It's processing is a subset of feed processing. If the processing or content model of entry is extended, it applies to both feed documents and entry documents. I disagree. There’s not much of a point in subscribing to an entry document, and APP servers will not accept POSTing feeds in place of entries. Well, it's kinda undefined - and this is circular - it's undefined because feeds and entries share a media-type. It would be useful to allow collections to accept non-atoms (har har). [EMAIL PROTECTED] expressed a need for batching, and I could really do with this for website/cms publishing. But because error handling semantics can be different for batches, it's tricky; some uniformity is lost if it's not thought out. cheers Bill
Re: PaceEntryMediatype
On Nov 30, 2006, at 2:13 AM, Jan Algermissen wrote: On Nov 29, 2006, at 7:22 PM, James M Snell wrote: One such problem occurs in atom:link and atom:content elements. Specifically: atom:link type=application/atom+xml href=a.xml / atom:content type=application/atom+xml src=b.xml / Given no other information I have no way of knowing whether these are references to Feed or Entry documents. And what is the problem with that? Here's one problem: in this and the autodiscovery case, the UA can't tell without fetching the remote resource whether it's appropriate to display a subscribe link. In fact, even if the remote resource is a feed, it may not be appropriate to subscribe to, because it may be an archive document rather than the live end of a feed. Of the options presented, I'd favor adding a type parameter to application/atom+xml. In addition to feed and entry, we may want archive.
Re: PaceEntryMediatype
Thomas Broyer wrote:
snip
I'd largely prefer augmenting the existing media type with a 'type'
parameter:
- application/atom+xml = either feed or entry (as defined in RFC4287)
- application/atom+xml;type=feed = feed
- application/atom+xml;type
=entry = entry
/snip
+1
On 11/29/06, Thomas Broyer [EMAIL PROTECTED] wrote:
2006/11/29, James M Snell:
Create a new media type for Atom Entry Documents:
application/atomentry+xml
Deprecate the use of application/atom+xml for Entry Documents.
I'd largely prefer augmenting the existing media type with a 'type'
parameter:
- application/atom+xml = either feed or entry (as defined in RFC4287)
- application/atom+xml;type=feed = feed
- application/atom+xml;type=entry = entry
{{{
Atom Entry Documents are identified with the
application/atomentry+xml media type (See section 15).
}}}
How about defining a tree similar to the */vnd.* one?
- application/atom+xml = feed or entry document
- application/atom.categories+xml = category document
- application/atom.service+xml = service document
...and of course, if this proposal is finally accepted:
- application/atom.entry+xml = entry document
As for Tim's concerns, I'd also prefer having it done outside the APP.
Also, the APP draft would need to be updated to remove the entry
special value for app:accept, as it would be equivalent to the new or
revised media type (app:accept=application/atom+xml;type=entry or
app:accept=applicationAtom.entry+xml)
--
Thomas Broyer
Re: PaceEntryMediatype
Mark Baker wrote: Interesting, thanks. But serving different purposes doesn't necessitate a new media type. What's important is how the two types of documents are interpreted. How does your processing of an entry document differ from the processing of a feed containing (only) that same entry? If processing the entry is a subset of processing the feed, then you probably don't need a new media type. Well having two media types also helps at a lower level such as HTTP (content negotiation for one thing). - Sylvain Mark. On 11/30/06, James M Snell [EMAIL PROTECTED] wrote: Mark Baker wrote: [snip] Yes, but more than that. An entry document is, AFAICT, little more than shorthand for a feed with one entry, minus the feed-specific metadata. It's processing is a subset of feed processing. If the processing or content model of entry is extended, it applies to both feed documents and entry documents. Hmm.. I understand what you're saying but I don't think I agree. In the APP implementations I've put together, Feed and Entry documents generally serve two entirely different purposes and are usually intended for two entirely different audiences. - James
Re: PaceEntryMediatype
2006/11/30, Mark Baker: The real problem here AIUI - at least in the context of HTML 5's inferred rel=feed bit - is not just entry documents, it's any Atom document which wouldn't normally be considered a feed by a typical user; something that most people would be interested in subscribing to. An example I gave on the whatwg list was an MHTML-like (MIME multipart) package, but there are many other possible examples of course; not all RFC 4287 feed documents are feeds in this sense. Yes. If HTML 5 (and current practice) doesn't change, but we defer to them for the specification of autodiscovery, then a new media type would be one way forward. But it should be reusable for all non-feed (i.e. from a user POV, as above) Atom documents, not just entry documents; perhaps application/atom-no-feed+xml. It's an ugly hack, but it's better than the alternative of many more specific Atom-related media types, which atomentry+xml might set a precedent for. -1 This means RSS would need two media types. This also means an HTML document can be a feed, or it needs its own media type. In an entry page in a blog-like scenario, we could find: link rel=feed href=/feed.atom type=application/atom+xml;type=feed link rel=feed href=/ type=text/html which tells you the page believes it is an item in the linked feeds. Then , in /feed.atom: atom:link rel=alternate href=/ type=text/html / and in the /: link rel=alternate href=/feed.atom type=application/atom+xml;type=feed And yes, HTML pages are subscribable, either using a microformat (see the W3C's home page, from which the RSS is actually produced using an XSLT stylesheet), or using user-defined scrapping (some aggregators allow you to subscribe to any web page; they try to infer the entries from the semantical markup –h1, h2, h3, etc.– and you can customize the mechanism in per-feed basis: this page uses h2, this one uses h3 with class=article, etc.) The relation from the entry page to the feed or home page is the same (hey, they are alternates!): they are feeds, whatever their representation (Atom, RSS, HTML, etc.) The difference with container? a feed is known to have a representation which only exposes a subset of the contained items. This is the same as: link rel=contents href=/toc.html type=text/html link rel=contents href=/toc.opml type=what's the media type for OPML? Another way forward, because the rel=feed inference is triggered not just by the media type but by the alternate relationship keyword, is to create a non-feed alternate relationship (alternate-non-feed? ick). I prefer the new relationship to a new media type because it's less disruptive; it doesn't require futzing around with existing specs and implementations. I'd prefer basing autodiscovery on the media types and not at all on the relationships. A feed relationship would only help finding the living resource (similar to rel=current in the Atom Relationship Registry) if you're not already on it (in which case, rel=alternate would be used). UAs would then obviously continue to support autodiscovery using alternate all-over-the-place, this would just be a lucky side-effect; and everyone would be happy. -- Thomas Broyer
Re: PaceEntryMediatype
On 11/30/06, Sylvain Hellegouarch [EMAIL PROTECTED] wrote: How does your processing of an entry document differ from the processing of a feed containing (only) that same entry? If processing the entry is a subset of processing the feed, then you probably don't need a new media type. Well having two media types also helps at a lower level such as HTTP (content negotiation for one thing). True, but if entry documents are more or less aliases for single-entry feeds, why would anybody need to negotiate for one or the other? I suggest that would have to be pretty obscure use case. 8-) Mark.
Re: PaceEntryMediatype
Well, it's all XML parsing so in one sense the processing is the same. The key difference arises in how the various documents are used. In my experience, Atom Entry Documents are nearly the exclusive territory of APP Clients and push notification services (e.g. Atom over XMPP) while Feeds generally provide for the redistribution and indexing of entries. When I parse an entry document, there is no implied feed. - James Mark Baker wrote: Interesting, thanks. But serving different purposes doesn't necessitate a new media type. What's important is how the two types of documents are interpreted. How does your processing of an entry document differ from the processing of a feed containing (only) that same entry? If processing the entry is a subset of processing the feed, then you probably don't need a new media type. Mark. On 11/30/06, James M Snell [EMAIL PROTECTED] wrote: Mark Baker wrote: [snip] Yes, but more than that. An entry document is, AFAICT, little more than shorthand for a feed with one entry, minus the feed-specific metadata. It's processing is a subset of feed processing. If the processing or content model of entry is extended, it applies to both feed documents and entry documents. Hmm.. I understand what you're saying but I don't think I agree. In the APP implementations I've put together, Feed and Entry documents generally serve two entirely different purposes and are usually intended for two entirely different audiences. - James
Re: PaceEntryMediatype
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 new media type approach would likely be far less disruptive. - James Antone Roundy wrote: [snip] Of the options presented, I'd favor adding a type parameter to application/atom+xml. In addition to feed and entry, we may want archive.
Re: PaceEntryMediatype
Jan Algermissen wrote: [snip] Are there other problems you had in mind when writing the Pace? Well, there are the issues that came up with regards to the APP accept element; the issues regarding whether Atom Feeds can be posted to an APP collection; the issue in the collection of collections use case where it's not clear if content type=application/atom+xml src=foo / points to an entry or a feed; I'm sure there are others that I'm not thinking of right at the moment. It seems that every couple of months the issue of the media type duality comes up. - James
Re: PaceEntryMediatype
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. Of course it does. Any program interested in consuming information is going to ignore unknown parameters. -- Robert Sayre
Re: PaceEntryMediatype
Mark Baker wrote: [snip] If HTML 5 (and current practice) doesn't change, but we defer to them for the specification of autodiscovery, then a new media type would be one way forward. But it should be reusable for all non-feed (i.e. from a user POV, as above) Atom documents, not just entry documents; perhaps application/atom-no-feed+xml. It's an ugly hack, but it's better than the alternative of many more specific Atom-related media types, which atomentry+xml might set a precedent for. Blech! :-) I think it's worthwhile to separate the two distinct issues at play: The Purpose of the Link and the Type of Resource. The ambiguity in the media type has come up several times in WG discussions for more than just autodiscovery. Every time it comes up there is some speculation about whether adding a type parameter would be helpful then folks move on to something else without really coming to a conclusion. I agree with you that the HTML5 definition of alternate is lacking but I understand why they've done things that way and I applaud their effort. They're documenting existing practice even if it is fundamentally flawed. At least they're moving things in the right direction with the feed link relation but it's too early to tell if that effort is going to pan out in the end. [snip] I prefer the new relationship to a new media type because it's less disruptive; it doesn't require futzing around with existing specs and implementations. Possibly. But at this point I'm not yet convinced. - James
Re: PaceEntryMediatype
Well it's all octets so in one sense the processing is the same. I have to agree with James. The right questions in my mind is this - how is processing an entry different from processing a feed with that and 42 entries? The idea that an entry is a degenerate feed is interesting, but unsubstantiated. Seriously, i'm not getting it. My experience is the opposite now, across 3 protocols; feeds are the odd men out (http needs them to deliver collections) and entries are not subsets of feeds. If there's real uniformity, I don't see it. To see it, I'd need to see that feeds and entries are closed under processing, and probably structurally isomorphic. We've enough field experience that suggests having entries and feeds sharing a media type is at best inconvenient. I only have to start thinking about how an APP collection handles partial update failures on a feed to think I need a dedicated media type for dealing with feeds. cheers Bill James M Snell wrote: Well, it's all XML parsing so in one sense the processing is the same. The key difference arises in how the various documents are used. In my experience, Atom Entry Documents are nearly the exclusive territory of APP Clients and push notification services (e.g. Atom over XMPP) while Feeds generally provide for the redistribution and indexing of entries. When I parse an entry document, there is no implied feed. - James Mark Baker wrote: Interesting, thanks. But serving different purposes doesn't necessitate a new media type. What's important is how the two types of documents are interpreted. How does your processing of an entry document differ from the processing of a feed containing (only) that same entry? If processing the entry is a subset of processing the feed, then you probably don't need a new media type. Mark. On 11/30/06, James M Snell [EMAIL PROTECTED] wrote: Mark Baker wrote: [snip] Yes, but more than that. An entry document is, AFAICT, little more than shorthand for a feed with one entry, minus the feed-specific metadata. It's processing is a subset of feed processing. If the processing or content model of entry is extended, it applies to both feed documents and entry documents. Hmm.. I understand what you're saying but I don't think I agree. In the APP implementations I've put together, Feed and Entry documents generally serve two entirely different purposes and are usually intended for two entirely different audiences. - James
Re: PaceEntryMediatype
Mark Baker wrote: [..] it it's better than the alternative of many more specific Atom-related media types, which atomentry+xml might set a precedent for. One question and one observation. The question: how will this set a precedent? The observation: if we really want to avoid this problem (assuming there is a problem), then RDF was the answer, not a pretence of uniformity. cheers Bill
