Subject: PaceEnclosuresAndPix status

From: Tim Bray <[email-masked]>
Date: Mon, 24 Jan 2005 16:18:00 -0800

If there were no further discussion: Got no -1's, seems useful, needed 
for feature parity with RSS2, will likely go in absent some objections. 
  -Tim

---

From: Joe Gregorio <[email-masked]>
Date: Mon, 24 Jan 2005 20:18:20 -0500

+1

Should there be a suggested size for images?

   -joe

-- 
Joe Gregorio        http://bitworking.org

---

From: Tim Bray <[email-masked]>
Date: Mon, 24 Jan 2005 17:25:44 -0800

> Should there be a suggested size for images?

A suggested aspect ratio, actually.  Drat.  Brent Simmons loved this 
idea, and I meant to update the draft.  Would anyone be upset if I 
updated the draft to say an aspect ratio of 2 (horizontal) to 1 
(vertical)?  -Tim

---

From: Graham <[email-masked]>
Date: Tue, 25 Jan 2005 01:53:34 +0000

> Should there be a suggested size for images?

Yes. -1 on images section if suggested sizes aren't added. I think 
favicons are more commonly displayed than logo images, so a link type 
or at least suggested size for them would be welcome.

Graham

---

From: Antone Roundy <[email-masked]>
Date: Mon, 24 Jan 2005 20:08:36 -0700

On Monday, January 24, 2005, at 05:18  PM, Tim Bray wrote:

> for feature parity with RSS2, will likely go in absent some 
> objections.  -Tim
>
-0.7.  Turns <link> into a kitchen sink by using it to point to things 
that are intended to be pre-fetched and presented along with the 
content (image, at least, though perhaps not enclosure).  But given 
that we've failed to achieve consensus on any language to limit the 
range of uses of <link>, perhaps that argument is dead.

---

From: Bill de hÓra <[email-masked]>
Date: Tue, 25 Jan 2005 14:40:21 +0000

Tim Bray wrote:
> Would anyone be upset if I 

Not me. +1

cheers
Bill

---

From: Ray Slakinski <[email-masked]>
Date: Tue, 25 Jan 2005 10:40:57 -0500

+1 from me, I'm happy to see this added!

> for feature parity with RSS2, will likely go in absent some 

[-----]
Ray Slakinski

GnuPG Fingerprint:
C8AD 4847 2DA8 3469 079D  13F9 135D F0CF 1CFC FD03

Blog: http://ddll.sdf1.net

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Tue, 25 Jan 2005 17:59:54 +0100

On Mon, 24 Jan 2005 20:08:36 -0700, Antone Roundy <[email-masked]>  
wrote:

> that are intended to be pre-fetched and presented along with the content

I agree. I think we should have chosen another element name. <link> turns  
out to be HTML's <input> where just «everything goes». I don't like it,  
but if it has to be <link> or nothing, I'd go with <link>.

+2 to aspect ratio or image size, though, no matter what the element is  
called.

-- 
Asbjørn Ulsberg     -=|=-    http://virtuelvis.com/quark/
«He's a loathsome offensive brute, yet I can't look away»

---

From: Anne van Kesteren <[email-masked]>
Date: Tue, 25 Jan 2005 18:15:09 +0100

Asbjørn wrote:
>> -0.7.  Turns <link> into a kitchen sink by using it to point to 
>> things  that are intended to be pre-fetched and presented along with 
>> the content
>
> I agree. I think we should have chosen another element name. <link> 
> turns  out to be HTML's <input> where just «everything goes». I don't 
> like it,  but if it has to be <link> or nothing, I'd go with <link>.

Agreed. It also does not make sense because the LINK is supposed to 
point to something. It should not be used for embedding graphics. 
Someone can use the graphic within TAGLINE or so I guess. Or even in 
TITLE. (Using TYPE now, per -04 spec. It should be MODE.)

  <atom:title type="XHTML">
    <xhtml:img src="foo" alt="foo"/> bar
  </atom:title>

-- 
  Anne van Kesteren
  <http://annevankesteren.nl/>

---

From: Lucas Gonze <[email-masked]>
Date: Tue, 25 Jan 2005 10:49:42 -1000 (HST)

A suggestion on drafting of the pace: cardinality should be stated.

The idea of multiple parallel elements formatted per PaceEnclosuresAndPix 
was discussed with interest, and the cardinality of RSS 2.0 enclosure 
elements has been written up and discussed quite a lot, so the cardinality 
of PaceEnclosuresAndPix should be explicit.

- Lucas Gonze

---

From: Eric Scheid <[email-masked]>
Date: Wed, 26 Jan 2005 14:22:28 +1100

> but if it has to be <link> or nothing, I'd go with <link>.

I'm also -1 on this. It muddles the semantic of the <link> element.

e.

---

From: Dan Brickley <[email-masked]>
Date: Wed, 26 Jan 2005 04:44:46 -0500

* Ray Slakinski <[email-masked]> [2005-01-25 10:40-0500]
> +1 from me, I'm happy to see this added!

+1 likewise to http://www.intertwingly.net/wiki/pie/PaceEnclosuresAndPix

Dan

---

From: Danny Ayers <[email-masked]>
Date: Wed, 26 Jan 2005 20:32:15 +0100

+1.

(with proposed tweaks)

-- 

http://dannyayers.com

---

From: Tim Bray <[email-masked]>
Date: Wed, 26 Jan 2005 12:00:24 -0800

> updated the draft to say an aspect ratio of 2 (horizontal) to 1 

Hearing no objections, I modified the Pace to say the image SHOULD have 
an aspect ratio of 2 (horizontal) to 1 (vertical).  -Tim

---

From: Graham <[email-masked]>
Date: Thu, 27 Jan 2005 01:03:00 +0000

On 26 Jan 2005, at 8:00 pm, Tim Bray wrote:

> Hearing no objections, I modified the Pace to say the image SHOULD 
> have an aspect ratio of 2 (horizontal) to 1 (vertical).  -Tim

What's our story on favicons? Quite a few programs support them and 
most presumably do it by guessing the URI from the feed URI (or 
possibly downloading the home page and looking for the URI there). I 
think it's a hole in RSS that needs plugging by us.

Graham

---

From: Brent Simmons <[email-masked]>
Date: Wed, 26 Jan 2005 17:54:35 -0800

> think it's a hole in RSS that needs plugging by us.

I agree with that. It's something many feed producers care about -- I 
get email just about every day asking how to make a favicon appear in 
my software. And I always wish I could say that there's a way to 
specify it in the feed.

I would favor specifying that favicons should be 16 x 16, or at least 
that they should be square.

-Brent

---

From: Tim Bray <[email-masked]>
Date: Wed, 26 Jan 2005 18:03:34 -0800

> think it's a hole in RSS that needs plugging by us.

As far as I know, aggregators are using the same favicon that web 
browsers are.  This whole thing is a mess, there's even an official W3C 
TAG issue for it (http://www.w3.org/2001/tag/issues.html#siteData-36).  
Can we please leave it stinking by the side of the road for someone 
else to clean up?  -Tim

---

From: Tim Bray <[email-masked]>
Date: Wed, 26 Jan 2005 18:24:57 -0800

> that they should be square.

Uh, the way browsers do it is just like the way robots.txt works.  They 
do a GET on "/favicon.ico", hardwired path, and (at least some of them) 
just silently ignore it if it's not 16x16.  This sucks (just like 
/robots.txt sucks) because if you have multiple "sites" on the same 
host you're hosed.  This is *not* just an RSS/syndication problem, it's 
bigger, and I don't think we own it.  -Tim

---

From: Graham <[email-masked]>
Date: Thu, 27 Jan 2005 03:16:18 +0000

On 27 Jan 2005, at 2:24 am, Tim Bray wrote:

> Uh, the way browsers do it is just like the way robots.txt works.  
> They do a GET on "/favicon.ico", hardwired path, and (at least some of 
> them) just silently ignore it if it's not 16x16.  This sucks (just 
> like /robots.txt sucks) because if you have multiple "sites" on the 
> same host you're hosed.  This is *not* just an RSS/syndication 
> problem, it's bigger, and I don't think we own it.

Can you outline the problem[s] that having a icon link tag in the feed 
might cause? HTML already has a meta tag for it, so it seems like a 
simple feature-parity issue.

Graham

---

From: Sam Ruby <[email-masked]>
Date: Wed, 26 Jan 2005 22:25:29 -0500

Tim Bray wrote:
> /robots.txt sucks) because if you have multiple "sites" on the same host 
> you're hosed.  This is *not* just an RSS/syndication problem, it's 

Take a look at:

   http://lists.w3.org/Archives/Public/www-html/2003Jun/0132.html

For quite some time, my XHTML has contained the following:

   <link rel="shortcut icon" href="/favicon.ico"/>

Question: would it be of value to people like Graham and Brent if we 
were to "register" this rel value for Atom feeds?

- Sam Ruby

---

From: Eric Scheid <[email-masked]>
Date: Thu, 27 Jan 2005 14:39:27 +1100

> were to "register" this rel value for Atom feeds?

that's not "a" value. that's two @rel values, space delimited.

atom:@rel doesn't allow for multiple space delimited values.

e.

---

From: Brent Simmons <[email-masked]>
Date: Wed, 26 Jan 2005 19:48:15 -0800

On Jan 26, 2005, at 7:25 PM, Sam Ruby wrote:

>>> I agree with that. It's something many feed producers care about -- 
>>> I get email just about every day asking how to make a favicon appear 
>>> in my software. And I always wish I could say that there's a way to 
>>> specify it in the feed.
>>>
>>> I would favor specifying that favicons should be 16 x 16, or at 
>>> least that they should be square.
>> They do a GET on "/favicon.ico", hardwired path, and (at least some 
>> of them) just silently ignore it if it's not 16x16.  This sucks (just 
>> problem, it's bigger, and I don't think we own it.  -Tim
>
> Take a look at:
>

Yes, this would work for me.

-Brent

---

From: Tim Bray <[email-masked]>
Date: Wed, 26 Jan 2005 19:59:32 -0800

> simple feature-parity issue.

Well, I don't think we're after feature-parity with HTML :)

Seriously, the existing "HTML feature" by which we mean conventional 
web-browser feature, works by fetching /favicon.ico; so Atom client 
software can easily emulate that, giving us feature parity.  So what 
you're really requesting is a per-feed icon.  Write a Pace.  If you can 
get a few +1's quite likely nobody will stand in the way.  And if it 
didn't get in, few hearts would be broken. -Tim

---

From: Tim Bray <[email-masked]>
Date: Wed, 26 Jan 2005 20:01:19 -0800

> were to "register" this rel value for Atom feeds?

Heh, didn't know that.  Much better than hardwiring /favicon.ico.  So 
someone write a Pace already, it only needs 3 lines. -Tim

---

From: Sam Ruby <[email-masked]>
Date: Wed, 26 Jan 2005 23:38:25 -0500

> atom:@rel doesn't allow for multiple space delimited values.

http://lists.w3.org/Archives/Public/www-html/2003Jun/0133.html

- Sam Ruby

---

From: Eric Scheid <[email-masked]>
Date: Thu, 27 Jan 2005 15:34:36 +1100

> someone write a Pace already, it only needs 3 lines. -Tim

do we want a way of associating a favicon with a feed? yes.

does this mean we must use the <link> element for this?

is <link rel="favicon*" ... /> valid inside an <entry> element?

e.

* or whatever.

---

From: Eric Scheid <[email-masked]>
Date: Thu, 27 Jan 2005 16:40:37 +1100

> http://lists.w3.org/Archives/Public/www-html/2003Jun/0133.html

agreed, a single term @rel value is preferred.

the "shortcut icon" thing is borked ... the linked favicon is used for more
than just an icon for the shortcuts/bookmarks list in browsers, f'rinstance,
and the resource so linked is not a "shortcut" to the linking resource,
whatever that means (an html page with links to popular posts might be).

so, "icon" ... or "favicon".

I prefer the latter.

e.

---

From: Henri Sivonen <[email-masked]>
Date: Thu, 27 Jan 2005 10:26:56 +0200

> agreed, a single term @rel value is preferred.

I'd prefer an element, because the nature of the favicon reference is 
not that a user would want to manually follow the link. That is:

<icon src='...'> or <icon href='...'>

-- 
Henri Sivonen
[email-masked]
http://iki.fi/hsivonen/

---

From: Eric Scheid <[email-masked]>
Date: Thu, 27 Jan 2005 22:12:41 +1100

> <icon src='...'> or <icon href='...'>

I've drafted a Pace for this...

    http://www.intertwingly.net/wiki/pie/PaceIconAndImage

This competes with parts of PaceEnclosuresAndPix, and so have also written
PaceLinkEnclosure which simply strips out the Pix part.

    http://www.intertwingly.net/wiki/pie/PaceLinkEnclosure

e.

---

From: Eric Scheid <[email-masked]>
Date: Fri, 28 Jan 2005 01:46:48 +1100

resending with more appropriate subject line, just in case these two new
paces got lost in the thread...

e.

---

From: Antone Roundy <[email-masked]>
Date: Thu, 27 Jan 2005 08:38:07 -0700

> so, "icon" ... or "favicon".
I prefer the former.  "favicon" => "favorites icon".  I think 
"favorites" is a bad name for bookmarks--a person's reason for 
bookmarking something (or in the case of Atom, subscribing to a feed) 
may not have anything to do with how much they like it.  And besides, 
the icon is displayed (in some browsers at least) when you're viewing 
the page, not just when it's bookmarked.  I'd rather not propagate the 
use of the term.  Let's just call it what we know it is--an icon.

---

From: Antone Roundy <[email-masked]>
Date: Thu, 27 Jan 2005 09:08:34 -0700

> <icon src='...'> or <icon href='...'>
While I agree with this sentiment, the working group has rejected 
attempts to add language to the spec to limit the use of <link>, so I 
assume we do not have consensus on the desire to limit it's usage.  So 
that's not necessarily a very strong argument for creating new elements 
(not that there aren't other arguments for it).

Of the two options you listed, I'd prefer @src to @href...for reasons 
related to my agreement with the sentiment about the use of <link> 
here.  "src" is much more description of how the attribute's value is 
going to be used.

Which brings me to PaceIconAndImage--the pace itself makes forbids 
putting one of the attributes of Link Constructs in the elements 
(@rel).  Another of them (@href) is not accurately descriptive of what 
it would be used for.  Another of them (@title) doesn't seem very 
useful for icon (unless for accessibility--do people more involved in 
accessibility issues think that's needed--that it's going to be used to 
say anything more than "xyz.com's icon"?)  Is it really appropriate to 
call this a Link Construct?

Also, why limit this to feed/head, and not entry?  So that Atom feeds 
will be easily convertible to RSS 2.0?  Certainly there are ways to add 
images to entries in RSS 2.0, though not icons (as far as I'm aware), 
but I don't think that's a big deal.  Because 
link/@rel="enclosure|attachment" can be used for images at the entry 
level?  Then why not do the same at the feed level?  Because we don't 
have prior art for needing it at the entry level?  True for icons, less 
true for images, but still probably the strongest argument.  But I 
would still argue for allowing them in entries.

---

From: "Bob Wyman" <[email-masked]>
Date: Thu, 27 Jan 2005 12:03:36 -0500

Antone Roundy wrote:
> Also, why limit this to feed/head, and not entry?  So that Atom
> feeds will be easily convertible to RSS 2.0?
	Converting *to* RSS 2.0 shouldn't be a goal or even a consideration
in any Atom related discussions. Only conversion *from* RSS 2.0 is
interesting.
	If Atom is guaranteed to be convertible both to and from RSS 2.0
then Atom can never be more than RSS 2.0 and a great deal of the effort and
goodwill that has gone into Atom would be a complete waste of time.

		bob wyman

---

From: Eric Scheid <[email-masked]>
Date: Fri, 28 Jan 2005 10:05:40 +1100

> goodwill that has gone into Atom would be a complete waste of time.

but we shouldn't get spiteful about it. If it doesn't matter either way on
some point, why not allow compatibility? I'm saying it should be a
consideration and possibly even an assumption, but remembering that if there
is a good reason to go another route (and break compatibility) then that
trumps the case.

Lets not be incompatible for incompatibilities sake.!

e.

---

From: Eric Scheid <[email-masked]>
Date: Fri, 28 Jan 2005 10:02:37 +1100

On 28/1/05 3:08 AM, "Antone Roundy" <[email-masked]> wrote:

> but I don't think that's a big deal.

RSS compatibility is one reason, as described in the rationale.

Another is that we're not talking a generic image here, we're talking about
some kind of special "badge" or branding image, which doesn't make sense for
entries. You can still add whatever images (and other resources) you want to
an entry with <link>. Maybe we should rename the <image> element to <logo>?

> call this a Link Construct?

I used a Link construct to keep word count down. Otherwise we'd need to
define an extra four attributes which have exactly the same names as those
in Link Constructs, which seemed like unnecessary wordage. It would really
bloat the spec. Saying instead that it's a Link construct where one
attribute is meaningless is much easier to not only write, but also to read.

@rel - yeah, I wrestled with that myself too, but then remember that other
elements place additional constraints on Link constructs elsewhere (eg.
4.2.2). Also, @rel is a MAY, so it's not like it's totally breaking the
template.

@href - what ever do you mean here?

@title in <image> certainly might be used for @alt text, the same way it is
specced in RSS 2.0. That's why I left @title in.

@title in <icon> could be used for @alt text if the icon is displayed
someplace, or more likely simply ignored. The street will find a use for it,
or not.

e.

---

From: Eric Scheid <[email-masked]>
Date: Fri, 28 Jan 2005 10:59:51 +1100

On 28/1/05 10:02 AM, "Eric Scheid" <[email-masked]> wrote:

> I used a Link construct to keep word count down

and now with -05 published there is no generic Link Construct. I'll update
the pace with all the necessary extra wordage and bloat.

e.

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sat, 29 Jan 2005 06:22:16 +0100

>     http://www.intertwingly.net/wiki/pie/PaceIconAndImage

Nice. But if we have both atom:icon and atom:image for the feed, why do we  
need to do all kinds of wierd stuff to have images attached to Atom  
entries? Can't atom:image (perhaps not atom:icon) occur as a child of  
atom:entry too?

> This competes with parts of PaceEnclosuresAndPix, and so have also  
> written PaceLinkEnclosure which simply strips out the Pix part.

Right. So we include images of the feed with 'image', while images for  
entries with 'link'. That doesn't make sense. It also doesn't make much  
sense to have several elements to do the exact same thing. My head is  
screaming for atom:object here.

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sat, 29 Jan 2005 06:29:14 +0100

> (not that there aren't other arguments for it).

But using atom:link for images requires us also to add several new  
attribtues to it, which tells me that we are overloading atom:link to such  
an extent that we should look for another element. Let people link all  
they want to images, but if they want their images to actually appear in  
blog software, they need to use the appropriate element (which shouldn't  
be atom:link).

> here.  "src" is much more description of how the attribute's value is  

I agree with this, but still feel atom:link is a wrong element to stuff  
this into. atom:object or atom:embed would be much better, imo. Or maybe  
even xhtml:object.

> but I don't think that's a big deal.

Indeed. Images should be embeddable outside the atom:content, imo. Icons  
aren't that important, but if we create a general way of embedding  
graphical objects in Atom feeds (at both atom:feed and atom:entry level),  
people can use it for icons, images, movies and whatever they'd like.

Heck, if people want a 3 minute move in 32 x 32 pixels as their feed icon,  
and feed consumer software adds support for this, why should we stand in  
the way?

> Because link/@rel="enclosure|attachment" can be used for images at the
> entry level?  Then why not do the same at the feed level?  Because we
> don't have prior art for needing it at the entry level?  True for icons,
> less  true for images, but still probably the strongest argument.  But
> I would still argue for allowing them in entries.

I would argue that we need a general graphical embed-mechanism that should  
be shared between entries and feeds.

---

From: Eric Scheid <[email-masked]>
Date: Sat, 29 Jan 2005 16:47:09 +1100

> entries? Can't atom:image (perhaps not atom:icon) occur as a child of

Maybe "image" is the wrong name for the concept. We're not talking about
some random image associated with some entity, we're talking about a
branding badge or logo of some kind which is representative of the feed.

While entries may well have images of various kinds attached to them (cat
pictures, anyone?), the individual entries don't get branded with their own
logo/badge, do they?

Hmmm... maybe I'll rename it to atom:logo ... would that help?

e.

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sat, 29 Jan 2005 07:15:44 +0100

> branding badge or logo of some kind which is representative of the feed.

I know what we're talking about and still don't understand why embedding  
so-called «favorite icons» is so wildely different from embedding other  
types of graphical objects in feeds (at all levels) that it has to be done  
in a wildely different way.

We're trying to create a mechanism for embedding graphics, and in some  
cases the graphic has special meaning. Then let's of course assert that  
special meaning, but not by creating several completely different  
mechanisms for embedding graphics in Atom feeds!

> pictures, anyone?), the individual entries don't get branded with their  
> own logo/badge, do they?

If they do, that's none of our (or at least my) business. If people want  
icons for their entries, let them have it. If aggregator writers want to  
add support for bookmarking individual entries (it makes sense, doesn't  
it?), it would be a lot easier to find these entries later on if they had  
some kind of icon attached to them. That icon could of course be the same  
as the feed's, but it could also be something completely different.

The point is that if we have a general way of embedding graphical objects  
in Atom feeds, we don't need to differ between feed- and entry-level  
graphics. We only need to define some types of graphical objects that have  
special meaning so they can be treated specially by aggregators. One such  
graphical object is «icon». It is an embedded graphical object, but it's  
supposed to be shown in a special place in the aggregator.

> Hmmm... maybe I'll rename it to atom:logo ... would that help?

If the renamed element can be used to embed all sorts of graphical objects  
in both feeds and entries; yes. :)

---

From: Eric Scheid <[email-masked]>
Date: Sun, 30 Jan 2005 00:54:51 +1100

> in a wildely different way.

You talk of embedding images as if those images are some form of content,
but the Pace uses this language:

>>   an image resource which provides visual identification for a feed

... as such it would be better to think of the atom:icon and atom:badge/logo
in the same sense as atom:tagline -- they are descriptive meta-data, not
content. It's a fine distinction, but it's there.

e.