Re: [whatwg] PaceEntryMediatype
On Thu, 7 Dec 2006, Martin Atkins wrote: > > > > Feeds for this site > > > >Status feed > >News feed > >Links feed > > > > This makes a lot more sense to me. When that orange button lights on up > on my browser's toolbar, I tend to think of it as "subscribe to this > page", not "subscribe to some random thing that happens to be on this > site somewhere and may or may not have anything to do with this page." > > rel="feed" the way Ian has defined it sounds more like type="feed" to > me. (ignoring of course the fact that the type attribute actually takes > a MIME type.) Yes, indeed. The primary difference is that type="" is specific to individual MIME types, whereas rel="" is a generic way of saying what the remote document is and how to process it (at least, that's what "relationship" in this context has come to mean). > I think it's much more likely in the above scenario that those links in > Alexey's example would be links to HTML documents containing the items > from the feed, and *on there* would be the feed auto-discovery stuff. > That's how I'd author it, anyway. (and also, by extension, how I'd > expect other sites to author it.) That's an option, yes; but I don't think we should restrict authors to those techniques. On Fri, 8 Dec 2006, Alexey Feldgendler wrote: > > > > This is not how is defined in HTML5. > > 3.8.4: "The link element allows authors to indicate explicit > relationships between their document and other resources." > > What kind of explicit relationship do we have here? Hm, good point. Fixed. > > Then the browser wouldn't take these links and make them available in > > a "list of feeds" interface, which is the problem we are trying to > > solve. > > Current browsers easily make lists of all links found on the page by > enumerating all elements. I can't see why a list of feeds cannot be > a subset of that. The type attribute gives enough information for this, > especially if combined with the proposed ";type=feed". But we don't want to restrict the types of feeds to just the currently supported MIME types. Whether something is a feed or not is independent of it's type. On Sat, 9 Dec 2006, Alexey Feldgendler wrote: > > > > Well they sort of have a relation -- they're feeds that the author > > thinks the user would find useful. > > This is no more tight a relation than "a page that the author thinks the > user would find useful", which is usually expressed with rather than > . Indeed. But I don't see that as a problem. > > This is something that happens already in the real world -- I'm just > > trying to make the spec distinguish "alternate" from "feed" when it > > comes to such feeds. > > Whoever is doing it abuses . Only if we say it is abuse, which I don't think we should. What do we gain by classifying this as abuse? > rel="feed" means "the feed for the current document", rel="alternate" > means "an alternate representation of the current document". Therefore, > rel="alternate feed" means "alternate representation of the current > document by a feed". Actually the spec defines this in detail, and it doesn't quite match your definition. > > > Currently the orange RSS icon means "Subscribe to this page". This > > > is a lot more useful (in my opinion) than it meaning "subscribe to > > > some random thing". > > > No, it doesn't. It means "subscribe to something the author made > > available". Currently you have no way to know if it is the current > > page's feed or just a list of random related feeds. > > Surely the author could have referenced any irrelevant feed but that's > not a good thing to do. Conscious authors should only use rel="feed" as > defined in the spec. I agree, but the spec doesn't say what you want it to, and I'm not convinced that it should or that authors want it to. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] PaceEntryMediatype
On Thu, 7 Dec 2006, Alexey Feldgendler wrote: > >>> > >>> > >>>Feeds for this site > >>> > >>> > >>> > >>>This page links to the three feeds for this site. > > > > status.xml is just a resource that provides a syndication feed. It is > > not necessarily associated with a particular Web page. > > If there is no particular relation, then it should not be . The > element is for resources which are in specific typical relations > to the current document. Well, it's related in the sense that people looking at the current page might find it useful. I don't see that that is a problem. > I would mark it up like this: > > Feeds for this site > >Status feed >News feed >Links feed > > > Note the absence of rel attribute on the : there is no specific > typical relation between the current document and the referenced > resources. That's certainly an option (though I would recommend adding rel=feed), but I don't see that that makes any less useful here. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] PaceEntryMediatype
On Sat, 09 Dec 2006 04:01:14 +0600, Ian Hickson <[EMAIL PROTECTED]> wrote: Why is it useful for a browser to make a list of a bunch of random feeds that have no relation to one another or to the current page? Well they sort of have a relation -- they're feeds that the author thinks the user would find useful. This is no more tight a relation than "a page that the author thinks the user would find useful", which is usually expressed with rather than . This is something that happens already in the real world -- I'm just trying to make the spec distinguish "alternate" from "feed" when it comes to such feeds. Whoever is doing it abuses . rel="feed" means "the feed for the current document", rel="alternate" means "an alternate representation of the current document". Therefore, rel="alternate feed" means "alternate representation of the current document by a feed". Currently the orange RSS icon means "Subscribe to this page". This is a lot more useful (in my opinion) than it meaning "subscribe to some random thing". No, it doesn't. It means "subscribe to something the author made available". Currently you have no way to know if it is the current page's feed or just a list of random related feeds. Surely the author could have referenced any irrelevant feed but that's not a good thing to do. Conscious authors should only use rel="feed" as defined in the spec. -- Alexey Feldgendler <[EMAIL PROTECTED]> [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] PaceEntryMediatype
On Fri, 8 Dec 2006, Martin Atkins wrote: > Ian Hickson wrote: > > > > Then the browser wouldn't take these links and make them available in a > > "list of feeds" interface, which is the problem we are trying to solve. > > Why is it useful for a browser to make a list of a bunch of random feeds > that have no relation to one another or to the current page? Well they sort of have a relation -- they're feeds that the author thinks the user would find useful. This is something that happens already in the real world -- I'm just trying to make the spec distinguish "alternate" from "feed" when it comes to such feeds. > Currently the orange RSS icon means "Subscribe to this page". This is a > lot more useful (in my opinion) than it meaning "subscribe to some > random thing". No, it doesn't. It means "subscribe to something the author made available". Currently you have no way to know if it is the current page's feed or just a list of random related feeds. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] PaceEntryMediatype
Ian Hickson wrote: Then the browser wouldn't take these links and make them available in a "list of feeds" interface, which is the problem we are trying to solve. Why is it useful for a browser to make a list of a bunch of random feeds that have no relation to one another or to the current page? A list of feeds *for the current page* I can see a use for (that little orange RSS icon on my browser's toolbar), but for links to other "feeds" a list inside the page itself is perfectly adequate, especially if that link actually links to an HTML document that *itself* declares a the feed as a . Currently the orange RSS icon means "Subscribe to this page". This is a lot more useful (in my opinion) than it meaning "subscribe to some random thing".
Re: [whatwg] PaceEntryMediatype
On Fri, 08 Dec 2006 04:31:25 +0600, Ian Hickson <[EMAIL PROTECTED]> wrote: Feeds for this site This page links to the three feeds for this site. >>> status.xml is just a resource that provides a syndication feed. It is not >>> necessarily associated with a particular Web page. >> If there is no particular relation, then it should not be . The >> element is for resources which are in specific typical relations >> to the current document. > This is not how is defined in HTML5. 3.8.4: "The link element allows authors to indicate explicit relationships between their document and other resources." What kind of explicit relationship do we have here? >> I would mark it up like this: >> >> Feeds for this site >> >>Status feed >>News feed >>Links feed >> >> >> Note the absence of rel attribute on the : there is no specific >> typical relation between the current document and the referenced >> resources. > > Then the browser wouldn't take these links and make them available in a > "list of feeds" interface, which is the problem we are trying to solve. Current browsers easily make lists of all links found on the page by enumerating all elements. I can't see why a list of feeds cannot be a subset of that. The type attribute gives enough information for this, especially if combined with the proposed ";type=feed". -- Alexey Feldgendler <[EMAIL PROTECTED]> [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] PaceEntryMediatype
On Thu, 7 Dec 2006, Alexey Feldgendler wrote: >>> >>> >>>Feeds for this site >>> >>> >>> >>>This page links to the three feeds for this site. >> >> status.xml is just a resource that provides a syndication feed. It is not >> necessarily associated with a particular Web page. > > If there is no particular relation, then it should not be . The > element is for resources which are in specific typical relations > to the current document. This is not how is defined in HTML5. > I would mark it up like this: > > Feeds for this site > >Status feed >News feed >Links feed > > > Note the absence of rel attribute on the : there is no specific > typical relation between the current document and the referenced > resources. Then the browser wouldn't take these links and make them available in a "list of feeds" interface, which is the problem we are trying to solve. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] PaceEntryMediatype
On Thu, 7 Dec 2006, Thomas Broyer wrote: > > 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). "rel" keywords are independent keywords, multiple keywors can always be given at the same time. They only exception is "alternate" when combined with "stylesheet" which for historical reasons is treated as a single keyword. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] PaceEntryMediatype
Alexey Feldgendler wrote: On Wed, 06 Dec 2006 22:42:06 +0600, Ian Hickson <[EMAIL PROTECTED]> wrote: In your example, what's the relation between status.xml and this page? status.xml is just a resource that provides a syndication feed. It is not necessarily associated with a particular Web page. If there is no particular relation, then it should not be . The element is for resources which are in specific typical relations to the current document. I would mark it up like this: Feeds for this site Status feed News feed Links feed Note the absence of rel attribute on the : there is no specific typical relation between the current document and the referenced resources. This makes a lot more sense to me. When that orange button lights on up on my browser's toolbar, I tend to think of it as "subscribe to this page", not "subscribe to some random thing that happens to be on this site somewhere and may or may not have anything to do with this page." rel="feed" the way Ian has defined it sounds more like type="feed" to me. (ignoring of course the fact that the type attribute actually takes a MIME type.) I think it's much more likely in the above scenario that those links in Alexey's example would be links to HTML documents containing the items from the feed, and *on there* would be the feed auto-discovery stuff. That's how I'd author it, anyway. (and also, by extension, how I'd expect other sites to author it.)
Re: [whatwg] PaceEntryMediatype
On Wed, 06 Dec 2006 22:42:06 +0600, Ian Hickson <[EMAIL PROTECTED]> wrote: >>> I mean that the feed might contain items that were never part of the page >>> linking to the feed. For example, this page: >>> >>> >>>Feeds for this site >>> >>> >>> >>>This page links to the three feeds for this site. >>> >>> There are no items on that page, but it links to three feeds that the site >>> provides. >> In your example, what's the relation between status.xml and this page? > status.xml is just a resource that provides a syndication feed. It is not > necessarily associated with a particular Web page. If there is no particular relation, then it should not be . The element is for resources which are in specific typical relations to the current document. I would mark it up like this: Feeds for this site Status feed News feed Links feed Note the absence of rel attribute on the : there is no specific typical relation between the current document and the referenced resources. -- Alexey Feldgendler <[EMAIL PROTECTED]> [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] 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 and not 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 in the of the page, where actually it uses no rel="" at all). So why the hell is it using rel="alternate"? (in a in the 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 and had a default value (let's say rel="related"), then this value could be used in the required rel="" attribute of when linking to feeds which are neither rel="alternate" or rel="feed" (with the definition given above, *not* the one from HTML5): 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: [whatwg] PaceEntryMediatype
On Wed, 6 Dec 2006, Alexey Feldgendler wrote: > On Tue, 05 Dec 2006 00:54:04 +0600, Ian Hickson <[EMAIL PROTECTED]> wrote: > > > I mean that the feed might contain items that were never part of the page > > linking to the feed. For example, this page: > > > > > >Feeds for this site > > > > > > > >This page links to the three feeds for this site. > > > > There are no items on that page, but it links to three feeds that the site > > provides. > > In your example, what's the relation between status.xml and this page? status.xml is just a resource that provides a syndication feed. It is not necessarily associated with a particular Web page. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] PaceEntryMediatype
On Tue, 05 Dec 2006 00:54:04 +0600, Ian Hickson <[EMAIL PROTECTED]> wrote: > I mean that the feed might contain items that were never part of the page > linking to the feed. For example, this page: > > >Feeds for this site > > > >This page links to the three feeds for this site. > > There are no items on that page, but it links to three feeds that the site > provides. In your example, what's the relation between status.xml and this page? -- Alexey Feldgendler <[EMAIL PROTECTED]> [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] 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 > > without implying > > and without dropping the 'type' attribute entirely (which was the other > solution pointed out on the whatwg list). > > ~fantasai > >
Re: [whatwg] 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 without implying and without dropping the 'type' attribute entirely (which was the other solution pointed out on the whatwg list). ~fantasai
Re: [whatwg] PaceEntryMediatype
Thomas Broyer wrote: There's no need to fetch every link if you base your assumptions on the type="" attribute (and *only* the type="" attribute, not the combination with any special rel="" attribute value). How does this solution deal with, e.g. hAtom? http://microformats.org/wiki/hatom The content type does not help you there. Some other meta-information is necessary. Fair enough. They still exist, though. Browser vendors aren't going to stop supporting this. We would be just sticking our heads in the sand if we ignored this. Many things are marked as "deprecated" in earlier HTML versions, and are still supported by browsers. Also, as the misuse of rel="alternate" is not machine testable, and given that I don't propose "banning" the use of rel="alternate" for feed autodiscovery, I can't see how a browser vendor could "stop supporting this". I agree that misusing "alternate" to link to feeds that are not an alternate representation of the page should be non-conforming. Of course yes, and they will be discovered based on the content-type, and rel="" will deserve its real role: describing the relationship between the two resources (and not describing the other end of the link). I agree that the "feed" link type is not /quite/ a proper link type-- it's more of a meta-content-type--but I've come to conclusion that the problem it solves, and how neatly it solves it, eclipses this (subtle) semantic distinction. Definition of feed: a bag of items; the representation of a feed generally exposes only the 10, or so, latest created or updated items. You'll note that this has nothing to do with the feed "format" (Atom, RSS, a Web log's homepage in HTML, etc.) If a document was once linked from a feed's representation as an item, it is an item of this feed, even if the feed's current representation doesn't link to it anymore. The relationship still exists. This relationship is "I am an item of this feed" or "this is a feed within which I once appeared". I propose representing it as rel="feed". ... Anyway, if you link to something, there's a reason. This reason is that there is a relationship between the current document and the thing the link points to. This relationship is described in the rel="" attribute. "It is *a* feed" is not a valid reason, it doesn't describe a relationship. "This is an alternate representation of this page in a format you can subscribe to" is a valid reason: it's an alternate representation. "I am an item of this feed" is a valid reason: I was once linked from it, so you'll find other similar things you might be interested in (because they are from the same author, or about the same subject, etc. this is to be "explained" to the user using the title="" attribute, that's not something a "machine" has to know about). That's an interesting relationship. Perhaps it could be expressed as "index feed" within the context of WA1.0's current link type definitions. In any case, I would like to see this use case definitively addressed. Such a link would be the most appropriate default feed to subscribe to from an entry page, if it were somehow clearly labelled. ~fantasai
Re: [whatwg] PaceEntryMediatype
On Mon, 4 Dec 2006, Thomas Broyer wrote: > > There's no need to fetch every link if you base your assumptions on the > type="" attribute (and *only* the type="" attribute, not the combination > with any special rel="" attribute value). If you don't use the type="" > attribute on s, you'll have many more requests than if you did, > because of the "fetch to discover the content-type" algorithm described > for elements, but that's the author problem, and it's not limited > to feed autodiscovery, so… So your proposal is to ignore the rel="" attribute altogether for feed autodiscovery? This seems contrary to what you were saying before, namely that there should be a way to give links to Atom documents that aren't feeds and have them not be autodetected. This isn't what you were proposing before as far as I can tell. > > > No more than they already are. rel="alternate" is for linking to > > > alternate representations, and hundreds of millions of syndication > > > feed links are not using it that way; they already are > > > non-conforming. > > > > Fair enough. They still exist, though. Browser vendors aren't going to > > stop supporting this. We would be just sticking our heads in the sand > > if we ignored this. > > Many things are marked as "deprecated" in earlier HTML versions, and > are still supported by browsers. > Also, as the misuse of rel="alternate" is not machine testable, and > given that I don't propose "banning" the use of rel="alternate" for > feed autodiscovery, I can't see how a browser vendor could "stop > supporting this". If you don't want browsers to implement the spec, why do you care what the spec says? I'm confused. If the specification is ignored by browser vendors, as you seem to be advocating, then the specification is useless. > > When people link to an Atom document, they are giving a syndication > > feed. I'm sure theoretically there could be other uses of Atom, but > > from my studies of Web content, I haven't seen any evidence that this > > is widespread enough to deserve special treatment. > > Seems like you really didn't understand my point… > « rel="alternate" + type="RSS or Atom" means rel="feed alternate" » > *is* special treatment. Which is justified, since feeds _are_ widespread. I was saying that non-feed Atom documents are not widespread and that _they_ don't deserve special treatment, not the other way around. > « type="RSS or Atom" means it's a syndication feed, whichever the > rel="" value » is *not* special treatment. It would be the only way to create a hyperlink link with a element without also specifying a rel="" attribute; that seems like special treatment to me. It also seems like a *superset* of what the spec currently says. If you don't like what it says now, why would you like it to be even more general? > « rel="feed" means it's a feed –with *my* definition of the "feed" > relationship–, whichever the type="" value » is *not* special > treatment. The type="" attribute is not relevant when rel=feed is set, according to the current spec. Your definition was a subset of the current definition, and didn't cover some of the existing use cases. I don't see how it changes the processing of the type="" attribute at all. > > > In 4.4.3.1 (Link type "alternate"), remove this paragraph: > > > """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.""" > > > > Removing this paragraph breaks existing practices. > > No, it doesn't. > links to a > syndication feed, not because of the rel="alternate" or its > combination with the type="application/rss+xml", but just because of > the type="application/rss+xml". No, browsers need both to consider it a link to a feed. > We have a problem with application/atom+xml because it can represent > either a feed or a standalone entry, but the Atom WG is working on > this issue (either we'll have a new 'type' parameter: > application/atom+xml;type=entry, or a new media type: > application/atom.entry+xml), so Atom won't be any different from RSS. > And given that I redefine rel="feed" and feed autodiscovery (see > below), the above quoted paragraph is no longer appropriate. I don't see how. > > > Remove rel="feed" or, if you really think it's different from > > > rel="index", define it that way: > > > """The feed keyword indicates that the referenced document is a > > > syndication feed which is or has been linking to the current page as a > > > feed item. > > > For example, in a Web log, a page representing a single entry can link > > > to the Web log homepage and/or the Web log's Atom or RSS feed using > > > using the link type feed.""" > > > > There are syndication feeds that don't fit this definition. > > Of course yes, and they will be discovered based on the content-type, > and rel="" w
Re: [whatwg] PaceEntryMediatype
Le 3 déc. 2006 à 18:49, Ian Hickson a écrit : On Sun, 3 Dec 2006, Thomas Broyer wrote: What I mean is that "being syndication feed" is not a property of a relationship, it's a property of one end of the relationship (the resource the link "starts from" or "points to"); so it has nothing to do with the rel="" attribute. I agree, in principle. Unfortunately, for autodiscovery we have to have a mechanism that can advertise what the syndaication feeds are without requiring the UA to fetch every link, because fetching every link would be much slower (and on some networks, fiscally more expensive). I'd like to suggest a possible solution that would address these two issues at the same time. The type attributes allows for parameters after the mime type. So what about this: src="..."> src="..."> src="..."> If the type parameter "role" is not present, "role=feed" would be implied. Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
Re: [whatwg] PaceEntryMediatype
2006/12/4, Ian Hickson: On Sun, 3 Dec 2006, Thomas Broyer wrote: > > What I mean is that "being syndication feed" is not a property of a > relationship, it's a property of one end of the relationship (the > resource the link "starts from" or "points to"); so it has nothing to do > with the rel="" attribute. I agree, in principle. Unfortunately, for autodiscovery we have to have a mechanism that can advertise what the syndaication feeds are without requiring the UA to fetch every link, because fetching every link would be much slower (and on some networks, fiscally more expensive). There's no need to fetch every link if you base your assumptions on the type="" attribute (and *only* the type="" attribute, not the combination with any special rel="" attribute value). If you don't use the type="" attribute on s, you'll have many more requests than if you did, because of the "fetch to discover the content-type" algorithm described for elements, but that's the author problem, and it's not limited to feed autodiscovery, so… > > So you're proposing making the hundreds of millions of existing > > instances of syndication feed links non-conforming? > > No more than they already are. > rel="alternate" is for linking to alternate representations, and > hundreds of millions of syndication feed links are not using it that > way; they already are non-conforming. Fair enough. They still exist, though. Browser vendors aren't going to stop supporting this. We would be just sticking our heads in the sand if we ignored this. Many things are marked as "deprecated" in earlier HTML versions, and are still supported by browsers. Also, as the misuse of rel="alternate" is not machine testable, and given that I don't propose "banning" the use of rel="alternate" for feed autodiscovery, I can't see how a browser vendor could "stop supporting this". > And note that this is something that is not machine-testable, that's why > those hundreds of millions of syndication feed links are not caught as > "invalid" by validators, as they won't be whatever HTML5 finally says. When people link to an Atom document, they are giving a syndication feed. I'm sure theoretically there could be other uses of Atom, but from my studies of Web content, I haven't seen any evidence that this is widespread enough to deserve special treatment. Seems like you really didn't understand my point… « rel="alternate" + type="RSS or Atom" means rel="feed alternate" » *is* special treatment. « type="RSS or Atom" means it's a syndication feed, whichever the rel="" value » is *not* special treatment. « rel="feed" means it's a feed –with *my* definition of the "feed" relationship–, whichever the type="" value » is *not* special treatment. > In 4.4.3.1 (Link type "alternate"), remove this paragraph: > """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.""" Removing this paragraph breaks existing practices. No, it doesn't. links to a syndication feed, not because of the rel="alternate" or its combination with the type="application/rss+xml", but just because of the type="application/rss+xml". We have a problem with application/atom+xml because it can represent either a feed or a standalone entry, but the Atom WG is working on this issue (either we'll have a new 'type' parameter: application/atom+xml;type=entry, or a new media type: application/atom.entry+xml), so Atom won't be any different from RSS. And given that I redefine rel="feed" and feed autodiscovery (see below), the above quoted paragraph is no longer appropriate. > Remove rel="feed" or, if you really think it's different from > rel="index", define it that way: > """The feed keyword indicates that the referenced document is a > syndication feed which is or has been linking to the current page as a > feed item. > For example, in a Web log, a page representing a single entry can link > to the Web log homepage and/or the Web log's Atom or RSS feed using > using the link type feed.""" There are syndication feeds that don't fit this definition. Of course yes, and they will be discovered based on the content-type, and rel="" will deserve its real role: describing the relationship between the two resources (and not describing the other end of the link). Definition of feed: a bag of items; the representation of a feed generally exposes only the 10, or so, latest created or updated items. You'll note that this has nothing to do with the feed "format" (Atom, RSS, a Web log's homepage in HTML, etc.) If a document was once linked from a feed's representation as an item, it is an item of this feed, even if the feed's current representation doesn't link to it anymore. The relationship still exists. This relationship is "I am an item of this feed" or "this is a feed within which I once appeared". I propose representing it
Re: [whatwg] PaceEntryMediatype
On Sun, 3 Dec 2006, Thomas Broyer wrote: > > > > Oh. If you just mean that you don't think there should be a way to say > > that a particular document is a syndication feed, then I disagree. I > > would assert that the popularity of feed readers such as Bloglines, > > Google Reader, and so forth, is evidence that many other people find > > this feature useful as well. > > It all depends on the definition of "syndication feed". > > What I mean is that "being syndication feed" is not a property of a > relationship, it's a property of one end of the relationship (the > resource the link "starts from" or "points to"); so it has nothing to do > with the rel="" attribute. I agree, in principle. Unfortunately, for autodiscovery we have to have a mechanism that can advertise what the syndaication feeds are without requiring the UA to fetch every link, because fetching every link would be much slower (and on some networks, fiscally more expensive). > > > With my "proposal", existing content would still be found by "feed > > > autodiscovery", it would just be "semantically incorrect" in many > > > cases (from an "entry" page, when linking to the feed containing the > > > entry with rel="alternate"; the feed is not an alternate to the > > > entry; the use of rel="alternate" was just a hack to "display the > > > orange icon"). > > > > So you're proposing making the hundreds of millions of existing > > instances of syndication feed links non-conforming? > > No more than they already are. > rel="alternate" is for linking to alternate representations, and > hundreds of millions of syndication feed links are not using it that > way; they already are non-conforming. Fair enough. They still exist, though. Browser vendors aren't going to stop supporting this. We would be just sticking our heads in the sand if we ignored this. > And note that this is something that is not machine-testable, that's why > those hundreds of millions of syndication feed links are not caught as > "invalid" by validators, as they won't be whatever HTML5 finally says. When people link to an Atom document, they are giving a syndication feed. I'm sure theoretically there could be other uses of Atom, but from my studies of Web content, I haven't seen any evidence that this is widespread enough to deserve special treatment. > > Actually I'm even more confused now than before. Could you propose > > exact normative replacement text for the specification that would make > > you happy? In doing so, please consider these constraints: > > > > * We cannot define anything to do with the user interface, only the > >meaning of the link relationships, because user agents must be allowed > >to innovate in user interfaces (basically, only interoperability can > >be ensured, not homogeneity). > > > > * We don't want to break existing practices. If something is > >interoperably implemented and widely used, then it should continue to > >work in the same way. > > > > * The specification should be kept as simple as possible. > > In 4.4.3.1 (Link type "alternate"), remove this paragraph: > """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.""" Removing this paragraph breaks existing practices. > Remove rel="feed" or, if you really think it's different from > rel="index", define it that way: > """The feed keyword indicates that the referenced document is a > syndication feed which is or has been linking to the current page as a > feed item. > For example, in a Web log, a page representing a single entry can link > to the Web log homepage and/or the Web log's Atom or RSS feed using > using the link type feed.""" There are syndication feeds that don't fit this definition. For example, a home page could link to various feeds for things like planned outages, news, press releases, etc, not all of which might be on the page itself. > Anyway, in 4.4.3.7 (Link type "feed"), remove this paragraph: > """The first link, a, or area element in the document (in tree order) > that creates a hyperlink with the link type feed must be treated as > the default syndication feed for the purposes of feed > autodiscovery.""" > > Also remove the examples from this same section. > > If you really want to deal with feed autodiscovery (which I believe it > shouldn't be part of HTML5), add something like this to section 3.5.4 > (The link element; feed autodiscovery should be limited to > elements, and given that it's how it's done today, it causes no > backwards compatibility problem): > """For example, external resource links with the type attribute set to > the value application/rss+xml or the value application/atom+xml or > with the link type feed may be recognized as links to subscribable > resources for the purpose of feed autodiscovery. > """ T
Re: [whatwg] PaceEntryMediatype
2006/12/2, Ian Hickson: On Sat, 2 Dec 2006, Thomas Broyer wrote: > > And what is a "syndication feed", if not something that's > "subscribable"? > > I mean, there is no definition of "syndication feed", neither of "feed > autodiscovery" (what's the purpose of "feed autodiscovery", if not to > subscribe to such feeds?) > > In that sense, I really do think the spec is mentionning subscribing. Oh. If you just mean that you don't think there should be a way to say that a particular document is a syndication feed, then I disagree. I would assert that the popularity of feed readers such as Bloglines, Google Reader, and so forth, is evidence that many other people find this feature useful as well. It all depends on the definition of "syndication feed". What I mean is that "being syndication feed" is not a property of a relationship, it's a property of one end of the relationship (the resource the link "starts from" or "points to"); so it has nothing to do with the rel="" attribute. > With my "proposal", existing content would still be found by "feed > autodiscovery", it would just be "semantically incorrect" in many cases > (from an "entry" page, when linking to the feed containing the entry > with rel="alternate"; the feed is not an alternate to the entry; the use > of rel="alternate" was just a hack to "display the orange icon"). So you're proposing making the hundreds of millions of existing instances of syndication feed links non-conforming? No more than they already are. rel="alternate" is for linking to alternate representations, and hundreds of millions of syndication feed links are not using it that way; they already are non-conforming. And note that this is something that is not machine-testable, that's why those hundreds of millions of syndication feed links are not caught as "invalid" by validators, as they won't be whatever HTML5 finally says. > I hope I clarified my opinion. Actually I'm even more confused now than before. Could you propose exact normative replacement text for the specification that would make you happy? In doing so, please consider these constraints: * We cannot define anything to do with the user interface, only the meaning of the link relationships, because user agents must be allowed to innovate in user interfaces (basically, only interoperability can be ensured, not homogeneity). * We don't want to break existing practices. If something is interoperably implemented and widely used, then it should continue to work in the same way. * The specification should be kept as simple as possible. In 4.4.3.1 (Link type "alternate"), remove this paragraph: """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.""" Remove rel="feed" or, if you really think it's different from rel="index", define it that way: """The feed keyword indicates that the referenced document is a syndication feed which is or has been linking to the current page as a feed item. For example, in a Web log, a page representing a single entry can link to the Web log homepage and/or the Web log's Atom or RSS feed using using the link type feed.""" Anyway, in 4.4.3.7 (Link type "feed"), remove this paragraph: """The first link, a, or area element in the document (in tree order) that creates a hyperlink with the link type feed must be treated as the default syndication feed for the purposes of feed autodiscovery.""" Also remove the examples from this same section. If you really want to deal with feed autodiscovery (which I believe it shouldn't be part of HTML5), add something like this to section 3.5.4 (The link element; feed autodiscovery should be limited to elements, and given that it's how it's done today, it causes no backwards compatibility problem): """For example, external resource links with the type attribute set to the value application/rss+xml or the value application/atom+xml or with the link type feed may be recognized as links to subscribable resources for the purpose of feed autodiscovery. """ This could be added, for example, just after this paragraph: """For external resource links, user agents may use the type given in this attribute to decide whether or not to consider using the resource at all. If the UA does not support the given MIME type for the given link relationship, then the UA may opt not to download and apply the resource.""" And it could be accompagnied by examples: The following link: …indicates an alternate representation of the current document as an Atom Document, which might be subscribed to. If a document contains two links labeled as follows: …then it means the current document appears or has been appearing as a feed
Re: [whatwg] 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: [whatwg] PaceEntryMediatype
2006/12/1, Mark Baker: Urgh, sorry for my tardiness; I'm falling behind on my reading. On 11/30/06, Thomas Broyer 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. See the mail I just sent in response to Ian. Consider hAtom. If you went by media types alone, you'd be confronted with; Not particularly useful for subscription (or anything else for that matter) is it? How does hatom.html relates to the current page? Is it an alternate? is it a "container" (rel="up", rel="index")? why would I subscribe to such a thing if I don't know what it is about? (also, note that rel="" is required for elements). This would be better; It still doesn't tell me what it has to do with the page I'm looking at. I do agree there is a "problem" in these cases, and that's why I originally proposed keeping a rel="feed", but with a clear definition as a relationship (opposed to a "kind of resource I'm linking to"). Autodiscovery should ideally be based primarily on link types, and only secondarily - as an optimization - on media types. Even this should work; As long as hatom.html is a feed where the current page is (or has been) linked to as an "item". If you are already looking at hatom.html, your hAtom-aware browser should already provide you with a "subscribe to this page" link/button/etc. If you can't describe the relationship between the current page and hatom.html, there is little chance that this is a resource of interest and that the person reading the page will subscribe to it (at least without "visiting" it). With rel="feed" as a real relationship (à la rel="index"), autodiscovery can be (as it should have already been) based on media types (am I able to subscribe to such a thing?) *or* rel="feed", with an equal "priority". If it appears than my proposed rel="feed" really is identical to rel="index", then a new mean should be found (e.g. a new attribute ) Saying "this is something you can subscribe to (it's a feed)" is not talking about relationships. On the contrary, saying "this is an 'index' and it incidentally is something you can subscribe to (it's a feed; either by using the 'type' attribute an hypothetical 'subscribable' attribute)" is. -- Thomas Broyer
Re: [whatwg] PaceEntryMediatype
On Sat, 2 Dec 2006, Thomas Broyer wrote: > 2006/12/1, Ian Hickson: > > On Fri, 1 Dec 2006, Thomas Broyer wrote: > > > > > > A summary of my problem with HTML5's autodiscovery: - there > > > shouldn't be a 'rel' value for "subscribability", subscribability is > > > a matter of whether and how an UA can process content from a > > > particular media type > > > > Agreed. The spec doesn't mention subscribing, just that rel=feed means > > it's a syndication feed. > > And what is a "syndication feed", if not something that's > "subscribable"? > > I mean, there is no definition of "syndication feed", neither of "feed > autodiscovery" (what's the purpose of "feed autodiscovery", if not to > subscribe to such feeds?) > > In that sense, I really do think the spec is mentionning subscribing. Oh. If you just mean that you don't think there should be a way to say that a particular document is a syndication feed, then I disagree. I would assert that the popularity of feed readers such as Bloglines, Google Reader, and so forth, is evidence that many other people find this feature useful as well. > With my "proposal", existing content would still be found by "feed > autodiscovery", it would just be "semantically incorrect" in many cases > (from an "entry" page, when linking to the feed containing the entry > with rel="alternate"; the feed is not an alternate to the entry; the use > of rel="alternate" was just a hack to "display the orange icon"). So you're proposing making the hundreds of millions of existing instances of syndication feed links non-conforming? That seems about equivalent to closing the barn door after the horse has bolted, as they say. > [...] > > I hope I clarified my opinion. Actually I'm even more confused now than before. Could you propose exact normative replacement text for the specification that would make you happy? In doing so, please consider these constraints: * We cannot define anything to do with the user interface, only the meaning of the link relationships, because user agents must be allowed to innovate in user interfaces (basically, only interoperability can be ensured, not homogeneity). * We don't want to break existing practices. If something is interoperably implemented and widely used, then it should continue to work in the same way. * The specification should be kept as simple as possible. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] PaceEntryMediatype
2006/12/1, Ian Hickson:
On Fri, 1 Dec 2006, Thomas Broyer wrote:
>
> A summary of my problem with HTML5's autodiscovery:
> - there shouldn't be a 'rel' value for "subscribability",
> subscribability is a matter of whether and how an UA can process
> content from a particular media type
Agreed. The spec doesn't mention subscribing, just that rel=feed means
it's a syndication feed.
And what is a "syndication feed", if not something that's "subscribable"?
I mean, there is no definition of "syndication feed", neither of "feed
autodiscovery" (what's the purpose of "feed autodiscovery", if not to
subscribe to such feeds?)
In that sense, I really do think the spec is mentionning subscribing.
> - HTML5 shouldn't say anything about which media type is
> "subscribable": application/atom+xml can be an Atom Entry, and there
> might be other subscribable media types (some aggregators allow you to
> subscribe to HTML); in other words, there shouldn't be any assumption
> of subscribability *from within the spec*.
Agreed, within the constraints of backwards compatibility. While it
doesn't mention subscribing to them, there are two explicit values for the
type="" attribute which have been grandfathered into meaning rel=feed.
This is needed for compatibility with existing content and existing UAs,
and isn't something that we have any ability to change, given the
widespread use of these types for that purpose.
With my "proposal", existing content would still be found by "feed
autodiscovery", it would just be "semantically incorrect" in many
cases (from an "entry" page, when linking to the feed containing the
entry with rel="alternate"; the feed is not an alternate to the entry;
the use of rel="alternate" was just a hack to "display the orange
icon").
As for existing UAs, HTML5 adds a new rel="feed" to try to "fix" this
semantically incorrect existing markup, so existing UAs won't catch
those feeds. My opinion is that the curent definition of rel="feed" is
"bad", and the attempt of widening the feed autodiscovery algorithm is
also badly defined.
Example:
When you open an Atom feed in Firefox 2 or IE7 (and probably other
browsers too), the browsers gives a way to subscribe to the feed. Why
is it doing it? because it believes this is a "subscribable resource".
Why is it believing it? because the media type is know to be one of a
"potentially subscribable" resource.
When you include a element in an HTML page, you're describing a
relationship with another resource. If you give the media-type of this
resource and it is known to be one of a "potentially subscribable"
resource, the browser you help you subscribe to it, whichever the
relationship with the current page (alternate, up, etc.)
The relationship should help in understanding why the other resource
has been linked and what it means relative to the current page; i.e.
it should help in how to *display* the "subscribe to..."
link/button/menu/etc. ("subscribe to this page" –rel="alternate"–,
"subscribe to news on this site" –rel="XXX"–, etc.) The title
attribute is additional guidance for the user to choose whether he'll
want to subscribe.
Now, there also is a need to link from an 'item' to the 'containing
feed', because weblog authors often want to "provide autodiscovery"
for their site-wide feed from within "entry-level" pages.
Here comes the "feed" relationship in my "model", it really deals with
the relationship between the resources, and this relationship implies
"subscribability" (I –the entry– am part of a "feed of entries" which
you can find here; where "feed of entries" implies subscribability).
The definition of "feed" here is: a container of "items" whose
representation generally only exposes the most recently added and/or
updated items.
HTML5 adds an element. If an HTML5 page contains such an
element (and a priori more than one), it might mean that the page is
kind of a "feed" (see the W3C's homepage, or almost any blog's
homepage) and can be subscribed. There's no reason HTML5-aware UAs
couldn't propose a "subscribe to this page" mechanism, infering
"article metadata" from semantic markup (headings, , , , etc.)
Using a rel="feed" relationship as described above (which I believe is
*not* the one of the current WA1 draft), it is then also possible to
link from the "entry-level" page to the "feed" page:
UAs could then display a "(try to) subscribe to this site" link/button/etc.
Actually, after reading WA1 a bit closer, rel="index" could be
sufficient; there wouldn't even be a need for a new relationship.
> - rel="feed" could be useful, but as a real relationship between
> resources (the resource pointed to by a rel="feed" link is a 'feed' in
> which the "current" resource "believes" it appears or has appeared as a
> contained item), not as defined currently in HTML5.
It sounds like you're describing rel="feed alternate", which is a
syndication feed explicitly for the current document, as opposed to a
rel=feed on its own, which is a syndication
Re: [whatwg] 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: [whatwg] PaceEntryMediatype
On Fri, 1 Dec 2006, 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. Assuming that an "atom feed" is a feed, and an "atom entry" is an alternative format representation of the same document: ...does what you are asking for according to HTML5, as does: If an "entry" is something more special (e.g. if it is actually an edit interface), then register a new rel="" value for it, e.g. rel=edit: -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] 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: [whatwg] 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: [whatwg] 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: [whatwg] 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: 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: 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: [whatwg] PaceEntryMediatype
On 12/1/06, Kyle Marvin <[EMAIL PROTECTED]> wrote: I'm still listening to the debate, but Mark's argument resonates with me. Yes, Mark is starting to convince me as well. -- Robert Sayre
Re: [whatwg] 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; Not particularly useful for subscription (or anything else for that matter) is it? This would be better; Autodiscovery should ideally be based primarily on link types, and only secondarily - as an optimization - on media types. Even this should work; Mark.
Re: [whatwg] PaceEntryMediatype
On Fri, 1 Dec 2006, Thomas Broyer wrote: > > A summary of my problem with HTML5's autodiscovery: > - there shouldn't be a 'rel' value for "subscribability", > subscribability is a matter of whether and how an UA can process > content from a particular media type Agreed. The spec doesn't mention subscribing, just that rel=feed means it's a syndication feed. > - HTML5 shouldn't say anything about which media type is > "subscribable": application/atom+xml can be an Atom Entry, and there > might be other subscribable media types (some aggregators allow you to > subscribe to HTML); in other words, there shouldn't be any assumption > of subscribability *from within the spec*. Agreed, within the constraints of backwards compatibility. While it doesn't mention subscribing to them, there are two explicit values for the type="" attribute which have been grandfathered into meaning rel=feed. This is needed for compatibility with existing content and existing UAs, and isn't something that we have any ability to change, given the widespread use of these types for that purpose. > - rel="feed" could be useful, but as a real relationship between > resources (the resource pointed to by a rel="feed" link is a 'feed' in > which the "current" resource "believes" it appears or has appeared as a > contained item), not as defined currently in HTML5. It sounds like you're describing rel="feed alternate", which is a syndication feed explicitly for the current document, as opposed to a rel=feed on its own, which is a syndication feed for any random subject. > Actually my main problems are: > - the definition of rel="feed" It's not clear to me what you think needs changing. Could you suggest an explicit set of changes that would satisfy you? > - the assumption that rel="alternate"+Atom or rel="alternate"+RSS is > equivalent to rel="feed alternate" This is out of our hands, sadly. There are literally hundreds of millions of deployed elements that make those assumptions today. We can't break legacy UAs and documents. Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] PaceEntryMediatype
2006/11/30, Ian Hickson: On Thu, 30 Nov 2006, Thomas Broyer wrote: > > 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. So as far as I can tell, that's what HTML5 currently requires. Am I interpreting you correctly? Hmm, I'm afraid you don't. For some background, see these mails on the Atom lists: http://www.imc.org/atom-syntax/mail-archive/msg19100.html http://www.imc.org/atom-syntax/mail-archive/msg19107.html There's a parallel discussion on the Atom lists about the Atom media types. A summary of my problem with HTML5's autodiscovery: - there shouldn't be a 'rel' value for "subscribability", subscribability is a matter of whether and how an UA can process content from a particular media type - HTML5 shouldn't say anything about which media type is "subscribable": application/atom+xml can be an Atom Entry, and there might be other subscribable media types (some aggregators allow you to subscribe to HTML); in other words, there shouldn't be any assumption of subscribability *from within the spec*. - rel="feed" could be useful, but as a real relationship between resources (the resource pointed to by a rel="feed" link is a 'feed' in which the "current" resource "believes" it appears or has appeared as a contained item), not as defined currently in HTML5. Actually my main problems are: - the definition of rel="feed" - the assumption that rel="alternate"+Atom or rel="alternate"+RSS is equivalent to rel="feed alternate" -- Thomas Broyer
Re: [whatwg] PaceEntryMediatype
On Thu, 30 Nov 2006, Thomas Broyer wrote: > > 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. So as far as I can tell, that's what HTML5 currently requires. Am I interpreting you correctly? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] 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:
which tells you the page "believes" it is an "item" in the linked "feeds".
Then , in /feed.atom:
and in the "/":
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:
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
