Re: PaceIRI status
Martin Duerst wrote: ... Bjoern was making a vaild, but fine, point: Because we decided to refer to RFC2396bis, rather than to RFC2396, we already have bought into the fact that RFC2396bis allows percent-encoded domain names, and thus essentially requires IDN support. (apart from the basic fact that no resolver is required to resolve all URIs or IRIs) ... OK, thanks for making me aware of this subtle change. ... Regards, Julian -- green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Re: PaceEnclosuresAndPix status
* Ray Slakinski [EMAIL PROTECTED] [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 On 24-Jan-05, at 7:18 PM, Tim Bray wrote: 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
Re: PaceAttributesNamespace status
On Wed, 26 Jan 2005 01:20:58 +, David Powell [EMAIL PROTECTED] wrote: PaceAttributesNamespace I'm -1 on this. It seems to be authorising a RDF users to do a transform on Atom Syntax in order to make it more RDF/XML-like. That's really orthogonal from the intention. If RDF users have to transform the content in order to interpret it as RDF/XML (which they do), then they might as well transform it to a decent RDF model which properly models the entities and properties involved in the feed. We don't need the format spec to authorize RDF users to do this - they can just do it. True. But that decent RDF model will presumably be based on the model implicit in the Atom spec. But there are points which can't be carried from the spec as it stands into the world of resources at large - the unqualified attributes. I don't think that tweaking an Atom document and interpreting it as RDF/XML is going to produce a sensible RDF model. That isn't really the intention, although there's no reason to make the transformation any more complicated than it needs to be. There are also a number of technical problems: * The attribute namespace prefixing problem solved by this Pace * atom:author defaulting won't be modelled sensibly * The xml:lang and xml:base context won't be preserved by Text constructs and Extensions if they are modelled as RDF XML Literals.[1] * parseType=Resource / parseType=Literal needs to be assumed in certain places. Only the first is covered by this Pace. If we try to solve all of these problems, then we are going to have to do a fairly complicated transformation that needs to be applied to produce a what could end up a quirky sub-optimal model. This is extrapolating a lot way from the proposal. I'd rather us make sure that we have designed the format spec well enough that it has a clear model for core elements and extensions. Yes, exactly. Then the RDFers can come up with a clear well-designed RDF vocabulary for Atom and a mapping from Atom format to RDF (via XSLT?). There is a clear mapping of construct *names* from Atom to the RDF world (the element names have URIs), but the unprefixed attributes don't have URIs. I've just posted this as an informal proposal on the Wiki suggesting that we let an RDF mapping should be defined outside of the format specification, and that we should avoid making this impossible: http://intertwingly.net/wiki/pie/MinimalRdfProposal Interpreting Atom syntax as RDF/XML is not possible without applying transformations. I don't care about Atom syntax as RDF/XML per se, what I'm interested in is Atom as RDF. Atom should define a consistent model for its core elements. Exactly. What it currently lacks is unambiguous names for the attributes outside of document instances. Cheers, Danny. -- http://dannyayers.com
PaceAttributesNamespace is *not* about syntax!
I've added the following note to the Pace: A lot of the critical response to this Pace has been based on the assumption that it is about changes to the Atom syntax. Nothing could be farther from the truth. Within Atom format it will remain mandatory that documents are produced with no-namespace attributes. This Pace is about the model. Resources on the Web are generally given URIs. With RDF, it has been found useful to also assign URIs to relations, so they too are uniformly are uniquely defined. As it stands, most of the constructs and relations within Atom already have URIs - the element names are namespace-qualified. This isn't the case for the attributes. By saying that the no-namespace attributes can be interpreted as having names in the Atom namespace gives them URIs. As well as simplifying the RDF model the approach described in this Pace should also be useful for reusing Atom attributes in extensions. http://intertwingly.net/wiki/pie/PaceAttributesNamespace Cheers, Danny. -- http://dannyayers.com
Re: Issues with draft-ietf-atompub-format-04
At 13:01 05/01/26, Eric Scheid wrote: It's only clear what's going on when the reader juxtaposes the two sections, and realises that the concept named 'type' in section [3.1.1] is not the same concept named 'type' in section [3.5.2]. Without that juxtaposition, the reader might well never realise that 'type' != 'type' and conflate the two concepts. Even you made that mistake just now, and you're the editor of the document. Pity the poor reader. Looking at it from a usability of specifications p.o.v., it doesn't hurt to have cross references. I agree this is a problem. Either we find new names for the attributes so that each element has a different attribute, or we put pointers to the other 'type' attribute(s) in each section about a type attribute (and ideally also a table somewhere that shows all of them). If we don't do it, confusion will be guaranteed, and we will know we are the ones to blame. Regards,Martin.
Re: PaceAttributesNamespace is *not* about syntax!
Danny Ayers wrote: I've added the following note to the Pace: A lot of the critical response to this Pace has been based on the assumption that it is about changes to the Atom syntax. Nothing could be farther from the truth. Within Atom format it will remain mandatory that documents are produced with no-namespace attributes. This Pace is about the model. Resources on the Web are generally given URIs. With RDF, it has been found useful to also assign URIs to relations, so they too are uniformly are uniquely defined. As it stands, most of the constructs and relations within Atom already have URIs - the element names are namespace-qualified. This isn't the case for the attributes. By saying that the no-namespace attributes can be interpreted as having names in the Atom namespace gives them URIs. As well as simplifying the RDF model the approach described in this Pace should also be useful for reusing Atom attributes in extensions. http://intertwingly.net/wiki/pie/PaceAttributesNamespace Let's assume that there will be a non-normative appendix which describes the mapping of the Atom/XML syntax to RDF triples (possibly via a mapping to RDF/XML or possibly directly). Clearly, such an appendix would need to define a number of relations, and such relations are likely to make use of the Atom namespace. A simple introductory and declarative statement in that appendix that describes how such a mapping is done (attribute name + atom namespace) would most definately be in order. But, now lets examine the statement proposed in PaceAttributeNamespace. It essentially alerts producers of something that that they need to be aware of. Now a quesion: what do they need do different with the knowledge that the RDF mapping does this? I would assert the answer to this question is nothing. Meaning that this particular statement is not needed. Again, no issue with the mapping. No issue with describing the mapping alongside with the actual mapping. - Sam Ruby
Re: PaceAttributesNamespace is *not* about syntax!
On Wednesday, January 26, 2005, at 07:03 AM, Sam Ruby wrote: Let's assume that there will be a non-normative appendix which describes the mapping of the Atom/XML syntax to RDF triples (possibly via a mapping to RDF/XML or possibly directly). Clearly, such an appendix would need to define a number of relations, and such relations are likely to make use of the Atom namespace. A simple introductory and declarative statement in that appendix that describes how such a mapping is done (attribute name + atom namespace) would most definately be in order. Agreed. This issue should be addressed in an appendix rather than in the main body of the spec.
Re: PaceFeedLink
On 26 Jan 2005, at 2:37 am, Eric Scheid wrote: I also concur. An aggregator is free to do so, but I don't think it should be a requirement. We already have a mechanism for the publisher to redirect requests to a new location (HTTP 304, 301). An aggregator might also only do so in extremis - if the feed starts going 404, it could then try the last cached /feed/head/[EMAIL PROTECTED]'self']. Very, very good point. The text needs something along the lines of Atom producers MUST NOT expect consumers which found the document at a different URI to switch to requesting it from the URI specified., or something less clunky. Otherwise it's going to cause all sorts of problems and arguments. Graham smime.p7s Description: S/MIME cryptographic signature
Re: PaceFeedLink
On Jan 26, 2005, at 7:27 AM, Graham wrote: Very, very good point. The text needs something along the lines of Atom producers MUST NOT expect consumers which found the document at a different URI to switch to requesting it from the URI specified., or something less clunky. Otherwise it's going to cause all sorts of problems and arguments. +1. I can already hear the whiny emails in my head. It may be enough just to say Software which discovers that the FeedLink URI is different from that used to retrieve the atom:feed document containing MAY choose to use the FeedLink URI for subsequent fetches. -Tim
Re: PaceAttributesNamespace is *not* about syntax!
On 26 Jan 2005, at 15:03, Sam Ruby wrote: [...] But, now lets examine the statement proposed in PaceAttributeNamespace. It essentially alerts producers of something that that they need to be aware of. Now a quesion: what do they need do different with the knowledge that the RDF mapping does this? I would assert the answer to this question is nothing. Meaning that this particular statement is not needed. Again, no issue with the mapping. No issue with describing the mapping alongside with the actual mapping. I think your assertion is wrong. If they are consuming or producing extended Atom [1] they will know exactly what these extensions are referring to. It won't affect in the least consumers of simple, non extended Atom, but it will greatly help consumers and producers of extended atom. Now if you don't care about making their lives easier, then you have nothing to worry about in this pace. If you do, like I and many others, then this will be very helpful. - Sam Ruby [1] Should we call these molecules?
Re: PaceAttributesNamespace is *not* about syntax!
Graham the Robot [1], when real people come and ask me something I'll talk to them. Henry On 26 Jan 2005, at 18:01, Graham wrote: On 26 Jan 2005, at 4:37 pm, Henry Story wrote: I think your assertion is wrong. If they are consuming or producing extended Atom [1] they will know exactly what these extensions are referring to. It won't affect in the least consumers of simple, non extended Atom, but it will greatly help consumers and producers of extended atom. What will? To what does these extensions refer? How will it help who? You seem to have given up trying to get your ideas across to other people. (+1 on Sam's argument, btw) Graham [1] http://www.imc.org/atom-syntax/mail-archive/msg11659.html
Re: PaceIRI status
+1 on PaceIRI I'm a little hesitant on this because I'm not familiar with the issues, but it's something we'll probably all have to broach sometime soon. Martin seems to know what he's talking about ;-) On Wed, 26 Jan 2005 08:54:51 +0100, Julian Reschke [EMAIL PROTECTED] wrote: Martin Duerst wrote: ... Bjoern was making a vaild, but fine, point: Because we decided to refer to RFC2396bis, rather than to RFC2396, we already have bought into the fact that RFC2396bis allows percent-encoded domain names, and thus essentially requires IDN support. (apart from the basic fact that no resolver is required to resolve all URIs or IRIs) ... OK, thanks for making me aware of this subtle change. ... Regards, Julian -- green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 -- http://dannyayers.com
Re: PaceExtensionConstruct status
On Tue, 25 Jan 2005 02:10:28 +, David Powell [EMAIL PROTECTED] wrote: +1 (allowing room for tweaks) I'll try to post my suggested RDF road-map tomorrow - basically, I'd like to see: * an Atom syntax - RDF mapping defined in a separate I-D. * no changes to the Atom syntax for the sake of RDF. * a model that maps properly onto the core Atom concepts without getting tangled up in the Atom syntax. Yep. Expect +1s from me for anything along these lines. An appendix covering RDF compatibility mapping has been suggested. I would expect that to be brief (and wouldn't object to it being solely informative), with the bulk of the material appearing in the separate ID. But right now I'd say the challenge is to get the third item above sorted. I believe Henry's got most of an RDF/OWL model worked out - perhaps he could be persuaded to post it to the Wiki for nitpicking..? Correct me if I'm wrong - the tricky bit relating to content datatypes still needs figuring out, along with a couple of inconsistencies/weird structures within Atom. Cheers, Danny. -- http://dannyayers.com
Difference of TEXT and XHTML?
Quoting from draft-ietf-atompub-format-04: 3.1.1 type Attribute ... If the value is TEXT, the content of the Text construct MUST NOT contain child elements. Such text is intended to be presented to humans in a readable fashion. Thus, software MAY display it using normal text rendering techniques such as proportional fonts, white-space collapsing, and justification. ... If the value of type is XHTML, the content of the Text construct MAY contain child elements. The content SHOULD be XHTML text and markup that could validly appear directly within an xhtml:div element. Receiving software which displays the content MAY use the markup to aid in displaying it. Considering that TEXT MAY be white-space collapsed (why not SHOULD?) and XHTML allows anything that could go in div including text, isn't TEXT redundant? What's the difference between: atom:title type='TEXT'I do not like ![CDATA[]]marqueegt;/atom:title and atom:title type='XHTML'I do not like ![CDATA[]]marqueegt;/atom:title ? Shouldn't both render as I do not like marquee? FWIW, with the exception of content, I think allowing only %inline XHTML elements would make more sense than allowing %flow. -- Henri Sivonen [EMAIL PROTECTED] http://iki.fi/hsivonen/
Re: Difference of TEXT and XHTML?
On Jan 26, 2005, at 12:44 PM, Henri Sivonen wrote: What's the difference between: atom:title type='TEXT'I do not like ![CDATA[]]marqueegt;/atom:title and atom:title type='XHTML'I do not like ![CDATA[]]marqueegt;/atom:title ? Shouldn't both render as I do not like marquee? Yeah, but if you wanted to have 'not' in bold: title type='TEXT'I do not like lt;marquee/title (can't do it) title type='HTML'I do lt;bnotlt;/b like amp;lt;marquee/title title type='XHTML'I do bnot/b like lt;marquee/title (Hey, an example like that might be helpful in the spec.) FWIW, with the exception of content, I think allowing only %inline XHTML elements would make more sense than allowing %flow. Anyone else pro or con on this one? -Tim
Re: Difference of TEXT and XHTML?
On Jan 26, 2005, at 23:18, Tim Bray wrote: On Jan 26, 2005, at 12:44 PM, Henri Sivonen wrote: What's the difference between: atom:title type='TEXT'I do not like ![CDATA[]]marqueegt;/atom:title and atom:title type='XHTML'I do not like ![CDATA[]]marqueegt;/atom:title ? Shouldn't both render as I do not like marquee? Yeah, but if you wanted to have 'not' in bold: title type='TEXT'I do not like lt;marquee/title (can't do it) title type='HTML'I do lt;bnotlt;/b like amp;lt;marquee/title title type='XHTML'I do bnot/b like lt;marquee/title But if you can always substitute type='TEXT' with type='XHTML' but not the other way round, what's the point of having type='TEXT' in the spec? -- Henri Sivonen [EMAIL PROTECTED] http://iki.fi/hsivonen/
Re: Difference of TEXT and XHTML?
On Jan 26, 2005, at 12:44 PM, Henri Sivonen wrote: FWIW, with the exception of content, I think allowing only %inline XHTML elements would make more sense than allowing %flow. On Wed, 26 Jan 2005, Tim Bray wrote: Anyone else pro or con on this one? -Tim This has elegance and is intuitively appealing. However it would open up a can of worms with styling. CSS must go in the document head. Inline HTML or XHTML probably doesn't have access to the document head. XHTML doesn't have styling elements like font, HTML does. So there would have to be a provision to get CSS into the document head, which adds complexity instead of subtracting it. One thing -- my knowledge of XHTML is shallow, so I may be missing a solution to styling that doesn't require HTML. - Lucas Gonze
Re: Difference of TEXT and XHTML?
On Jan 26, 2005, at 1:31 PM, Henri Sivonen wrote: But if you can always substitute type='TEXT' with type='XHTML' but not the other way round, what's the point of having type='TEXT' in the spec? With type='TEXT' you know it's not going to contain any (X)HTML formatting, so you don't have to invoke your (X)HTML renderer. -Tim
Re: Difference of TEXT and XHTML?
On Jan 27, 2005, at 00:45, Robert Sayre wrote: But guess what, TEXT is *never* coming out of the spec, because it will eventually become impossible to write something that looks like markup if we don't have it. How so? What does type='TEXT' make possible to write that type='XHTML' with a single text node does not make possible to write? -- Henri Sivonen [EMAIL PROTECTED] http://iki.fi/hsivonen/
Re: PaceFeedLink
On 27/1/05 7:47 AM, Sjoerd Visscher [EMAIL PROTECTED] wrote: The whole point of xml:base is that an application that stores a page outside of its original context can add an xml:base to prevent losing the original location context. browsers don't. all they know is here is a URL to a resource, and here is a HTTP header which says the content is best handled by some other application, so it then saves the resource to disk and tells the other application to get a grip. It doesn't have to understand the content to do this, let alone munge the content. e.
Re: Difference of TEXT and XHTML?
On 27/1/05 9:24 AM, Henri Sivonen [EMAIL PROTECTED] wrote: Sorry, I don't understand what your example is demonstrating. How would the above be different from: title type='XHTML'Iamp;nbsp;doamp;nbsp;notamp;nbsp;likeamp;nbsp;lt; marquee/title title type='XHTML'Ido not like .../title try instead this example I 3 Huckabees... e.
Re: PaceEnclosuresAndPix status
On Jan 26, 2005, at 5:03 PM, Graham wrote: 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. 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
Re: PaceEnclosuresAndPix status
On Jan 26, 2005, at 5:54 PM, Brent Simmons 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. 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
Re: PaceAttributesNamespace is *not* about syntax!
Henry Story wrote: On 26 Jan 2005, at 15:03, Sam Ruby wrote: [...] But, now lets examine the statement proposed in PaceAttributeNamespace. It essentially alerts producers of something that that they need to be aware of. Now a quesion: what do they need do different with the knowledge that the RDF mapping does this? I would assert the answer to this question is nothing. Meaning that this particular statement is not needed. Again, no issue with the mapping. No issue with describing the mapping alongside with the actual mapping. I think your assertion is wrong. If they are consuming or producing extended Atom [1] they will know exactly what these extensions are referring to. It won't affect in the least consumers of simple, non extended Atom, but it will greatly help consumers and producers of extended atom. Now if you don't care about making their lives easier, then you have nothing to worry about in this pace. If you do, like I and many others, then this will be very helpful. It seems to me that you are both misunderstanding and mischaracterizing what I am saying. Furthermore, in other emails, I sense a confusion between RDF (which is a model) and RDF/XML (which is a syntax). I am in favor of AtomAsRDF (as a was to model this data). I am opposed to AtomAsRDFXML (as a syntax for expressing this model). If anybody is up to the task, I am for inclusion of prose into the standard describing how one is to interpret Atom feeds as RDF. Any such mechanism that accomplishes this will, by necessity, need to specify what namespace is used in the URIs used to define relationships. PaceAttributeNamespace does not do that. All it says is is that a given namespace may be used. For what purpose such a statement is made is entirely unclear. By contrast, a precise statement to the effect of how RDF aware tools MUST interpret Atom feeds if they are to interoperate is both clear and useful. - Sam Ruby
Re: Difference of TEXT and XHTML?
Henri Sivonen wrote: On Jan 26, 2005, at 23:46, Tim Bray wrote: On Jan 26, 2005, at 1:31 PM, Henri Sivonen wrote: But if you can always substitute type='TEXT' with type='XHTML' but not the other way round, what's the point of having type='TEXT' in the spec? With type='TEXT' you know it's not going to contain any (X)HTML formatting, so you don't have to invoke your (X)HTML renderer. Is it useful to support that kind of optimization on the format level? I would expect a feed renderer to use the same rendering approach for all titles for visual consistency. Even if a renderer chose to make optimizations, surely it could check for element children itself (which would be more robust than trusting the feed generator). I'm not so concerned about the optimization. But having observed quite a number of people tripping over double escaping rules in various flavors of RSS, I very much like having a very conservative default of TEXT. And then for those who wish to get more adventurous, there are two choices: XHTML (compact, clear, but must be well formed), and double escaped HTML (verbose, error prone, but can handle arbitrary content). - Sam Ruby
Re: Issues with draft-ietf-atompub-format-04
Robert Sayre wrote: * 3.5.1 rel Attribute Why are the only values defined alternate and related? I have implemented via for a long time on my personal weblog and some aggregators have even implemented support for it. I consider it to be quite useful. Write a Pace. I would support it. Yes, please. - Sam Ruby
Re: Questions about -04
Martin Duerst wrote: At 01:51 05/01/26, Asbjn Ulsberg wrote: On Wed, 12 Jan 2005 16:54:27 -0500, Sam Ruby [EMAIL PROTECTED] wrote: 2. Why MUST a feed point to an alternate version. [...] I'm -1 on removing this restriction. I thought we came to a sort of consensus that the link should be optional. Or was that only for atom:entry? Anyway, I think both of them should be optional. That is, I disagree with you, Sam. I agree with Asbjoern. Regards, Martin. There is consensus that atom:link is not required for atom:entries which contain content. That consensus has been reflected in the most recent drafts. That is not the question referred to above. There are now, by some counts, ten versions of formats that call themselves RSS. Every last one of then has a required channel/link. Every last one of them. Relaxing a restriction requires consumers to handle more cases. My expectation is that given limited demand for this feature, the more likely scenario is that consumers will either produce unexpected results or outright fail for feeds without this data. Because of this, I would like to request that there be a compelling use case be found which for feeds for which there can not be a atom:link defined. Note atom:link is defined as a URI. While most examples that we have seen use the HTTP scheme, this is not a requirement. Given that this is not a requirement, and given that existing RSS producers have come out in mass demanding that this restriction be lifted from RSS, I can only conclude that the burden seems rather low. - Sam Ruby
Re: Difference of TEXT and XHTML?
On Thu, 27 Jan 2005, Henri Sivonen wrote: On Jan 26, 2005, at 23:40, Lucas Gonze wrote: XHTML doesn't have styling elements like font, HTML does. Both XHTML 1.0 Transitional and HTML 4.01 Transitional have font. Neither XHTML 1.0 Strict nor HTML 4.01 Strict has font. Then my point is moot as long as XHTML inline content may be XHTML 1.0 Transitional. A second argument that inline XHTML may be XHTML 1.0 Transitional is that it satisfies the need for well-formed XML. So there would have to be a provision to get CSS into the document head, which adds complexity instead of subtracting it. Why would there have to be a method for shipping CSS for titles and similar text constructs? Because having control over presentation is the main reason to format content as HTML. - Lucas Gonze
Re: PaceMustBeWellFormed status
Sam Ruby wrote: The feedvalidator currently declares content served as text/plain as invalid. I would very much like to keep this check, for a number of reasons. What I am saying is that the Atom spec should allow consumers enough leeway to process such resources as non-feed (specifically, I would hope that they would process such resources as plain text). Section 2 says Both kinds of Atom documents are specified in terms of the XML Information Set, serialised as XML 1.0 [W3C.REC-xml-20040204] and identified with the application/atom+xml media type. Atom Documents MUST be well-formed XML. So, Atom documents are well-formed XML identified with the Atom media type. The specification doesn't talk about other media types or ill-formed XML documents. Is there something more we can add to the specification? I don't think PaceMustBeWellFormed is it. Robert Sayre
Re: PaceEnclosuresAndPix status
Tim Bray wrote: On Jan 26, 2005, at 5:54 PM, Brent Simmons 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. 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 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
Re: PaceEnclosuresAndPix status
On Jan 26, 2005, at 7:25 PM, Sam Ruby wrote: Tim Bray wrote: On Jan 26, 2005, at 5:54 PM, Brent Simmons 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. 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 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 Yes, this would work for me. -Brent
Re: PaceEnclosuresAndPix status
On Jan 26, 2005, at 7:25 PM, Sam Ruby wrote: 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? Heh, didn't know that. Much better than hardwiring /favicon.ico. So someone write a Pace already, it only needs 3 lines. -Tim
Re: PaceEnclosuresAndPix status
On 27/1/05 3:38 PM, Sam Ruby [EMAIL PROTECTED] wrote: atom:@rel doesn't allow for multiple space delimited values. e. 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.
