Re: Revised PaceIconAndImage, added PaceMultipleImages
I am +1 on having images, or what I call entry illustrations. BlogEd has those, and they work nicely. See http://today.java.net/jag/ or http://bblfish.net/blog for blogs that use them. Notice that the top entry (the Feed itself) has an illustration too. Which is another hint that a Feed is a subclass of an Entry. Of course if they did not make it into the spec it would be easy to add them as extensions. So the effort in speccing this would not be wasted. You may want to consider that an icon of an image is also related somehow to the original. In the feeds mentioned above, clicking on the icon brings you to a the original image the icon is a representation of. In one case [1] it occurred to me that have been more intuitive to have clicking on the image bring up a video. Henry Story [1] http://www.bblfish.net/blog/page3.html#25 On 2 Feb 2005, at 07:49, Tim Bray wrote: Having produced my own Atom feed has made me a supporter of this Pace; without getting too deep into it link rel=self feels quite sensible, while link rel=icon feels stupid. However, this Pace needed work; first of all, it was based on link constructs, which no longer exist. So I revised it. Second, along with turning Icon and Image from link into their own elements, it changed the cardinality, allowing more than one atom:image in atom:head. I think this is probably a bad idea, but I'm 100% sure that it's wrong to mix up this with the (entirely separate) debate on whether to use image instead of link. So, I ripped it out of PaceIconAndImage and created a new PaceMultipleImages to suggest this. Third, along with these other changes, the Pace changed the atom:image aspect ratio from 2:1 to 1:1. Once again, this may be a good idea, but it needs discussion. But I kind of think this may have been a cutpaste typo, so I ripped it out but didn't create a new Pace, if someone really wants to change the Aspect ratio they should create a Pace. Having said all that, I'm +1 on PaceIconAndImage. I'm -1 on PaceMultipleImages, this is an experimental feature, Atom, doesn't need those, YAGNI. -Tim
Revised PaceIconAndImage, added PaceMultipleImages
Having produced my own Atom feed has made me a supporter of this Pace; without getting too deep into it link rel=self feels quite sensible, while link rel=icon feels stupid. However, this Pace needed work; first of all, it was based on link constructs, which no longer exist. So I revised it. Second, along with turning Icon and Image from link into their own elements, it changed the cardinality, allowing more than one atom:image in atom:head. I think this is probably a bad idea, but I'm 100% sure that it's wrong to mix up this with the (entirely separate) debate on whether to use image instead of link. So, I ripped it out of PaceIconAndImage and created a new PaceMultipleImages to suggest this. Third, along with these other changes, the Pace changed the atom:image aspect ratio from 2:1 to 1:1. Once again, this may be a good idea, but it needs discussion. But I kind of think this may have been a cutpaste typo, so I ripped it out but didn't create a new Pace, if someone really wants to change the Aspect ratio they should create a Pace. Having said all that, I'm +1 on PaceIconAndImage. I'm -1 on PaceMultipleImages, this is an experimental feature, Atom, doesn't need those, YAGNI. -Tim
Re: Revised PaceIconAndImage, added PaceMultipleImages
On 2/2/05 5:49 PM, Tim Bray [EMAIL PROTECTED] wrote: Having produced my own Atom feed has made me a supporter of this Pace; without getting too deep into it link rel=self feels quite sensible, while link rel=icon feels stupid. +1 However, this Pace needed work; first of all, it was based on link constructs, which no longer exist. So I revised it. I based it on Link Constructs because I was (a) trying to avoid spec bloat, and (b) being lazy. The Link Construct did provide for more than just a URI though -- there's @type, a title attribute (which could be used for the @alt), and (pushing it) @hreflang for those atom:image with text rendered. I'm happy to lose @hreflang, a user agent could use /feed/head/tagline instead of @title, and @type really isn't necessary because the set of image formats is pretty stable. So, +1. (with minor revisions ... change the section numbers to suit -05, and added cardinality to section 4.2 the atom:head element, otherwise the spec wouldn't say just where those elements could be used) Second, along with turning Icon and Image from link into their own elements, it changed the cardinality, allowing more than one atom:image in atom:head. I think this is probably a bad idea, but I'm 100% sure that it's wrong to mix up this with the (entirely separate) debate on whether to use image instead of link. So, I ripped it out of PaceIconAndImage and created a new PaceMultipleImages to suggest this. +1. I wish more paces were decoupled. (makes note to self) Third, along with these other changes, the Pace changed the atom:image aspect ratio from 2:1 to 1:1. That must have been a copy/pasto. I know I set the atom:icon aspect ratio to 1:1, and thought I kept the 2:1 aspect ratio for atom:image. Once again, this may be a good idea, but it needs discussion. But I kind of think this may have been a cutpaste typo, so I ripped it out but didn't create a new Pace, if someone really wants to change the Aspect ratio they should create a Pace. Yep, copy/pasto ... no, wait ... it actually said: === 4.2.y atom:image Element === The atom:icon element is a Link construct that conveys a URI to an image resource which provides visual identification for a feed. The image SHOULD have an aspect ratio of 2 (horizontal) to 1 (vertical). 2:1, but I did have a copy/pasto brainfart with the name of the element in the prose of the section. Having said all that, I'm +1 on PaceIconAndImage. +1 I'm -1 on PaceMultipleImages, this is an experimental feature, Atom, doesn't need those, YAGNI. fair enough - there's been enough flack over multiple content. e.
