Re: IE7 Feed Rendering Issue
On 3/9/06, David Nesting [EMAIL PROTECTED] wrote: On 3/9/06, M. David Peterson [EMAIL PROTECTED] wrote: If, in fact, what you mean by this *IS* that its the end users choice, then I would tend to agree... as long as the option exists. That was, actually, what I was trying to say. Oops, I quoted the wrong thing. I was, in fact, trying to say the opposite: it's up to the consuming applications (feed readers) to decide how they want to render your feed. You cannot exert control over 100% of feed readers' presentations of your feed, since many of them will not resemble a web browser in any way. Therefore it is unreasonable for you to expect to have 100% control over feed readers that are also web browsers.That being said, as I noted in my earlier e-mail, I do agree that this IE behavior change breaks some non-traditional web sites (including some of my own), and that some sort of workaround is going to be needed.David
Re: IE7 Feed Rendering Issue
On 3/9/06, M. David Peterson [EMAIL PROTECTED] wrote: If, in fact, what you mean by this *IS* that its the end users choice, then I would tend to agree... as long as the option exists. That was, actually, what I was trying to say. You are publishing an XML feed, not a web page. You are publishing data, not a brochure. You cannot control how your feed renders in non-web browser feed readers. These readers may not resemble a web browser in any way. Feed aggregators are not going to preserve your style sheet. Your feed, within these aggregated feeds, is not going to look remotely like you intended. It won't look the same when converted to other feed dialects. There is no requirement in Atom that the xml-stylesheet be preserved. I don't think it is reasonable for one to expect that feed readers (built into web browsers or otherwise) are going to be keen on abandoning their own user interface guidelines because you'd prefer your entries to be formatted a particular way. If you want a web page, write your feed as an HTML page.I will, however, concede that IE has changed its behavior, and the behavior change is arguably something to get irritated about. Some of us build sites not with HTML, but with XML of various forms, and rely on xml-stylesheet to make our data-oriented site presentable in web browsers. In the past, users could click on links between, e.g., FOAF-as-HTML and Atom-as-HTML and their experience wouldn't be too different from any other web page. Now when they follow that link, they'll get a page that looks nothing like we intended. This is a bad user experience. So the real question is: How can site authors instruct a web browser-feed reader hybrid when it should treat an application/atom+xml document as a web page (via xml-stylesheet) and when it should treat it as a consumable feed? Perhaps it is reasonable for these types of applications to work like this: 1. If the feed is requested in the context of a web link, and it has an xml-stylesheet directive, treat it as a web page2. If the feed is requested within the context of the feed reading component of the application (thus no web context), or would simply be rendered as raw XML due to the lack of an xml-stylesheet processing instruction, treat it as a raw feed and present it subject to the feed reader UI guidelines. If there is no option provided, and simply its our way and only our way... deal with it then we will be left to deal with it just as mentioned: find legal ways around the system, and publishing/promoting these work arounds via the various means that the folks who feel such information is necessary to promote have at their disposal. I know at least a couple hundred folks myself that I know would be happy to publish such information as long as this information stayed within the confines of the end user and developer licensing agreements. Which it would. Could content negotiation work here? Publish both your application/xhtml+xml feed and a pre-transformed text/html variant under the same URL. I'm not too familiar with IE's feed reading capabilities here, but does it at least do enough to vary the Accept request header to make this work? David
Re: IE7 Feed Rendering Issue
On 3/9/06, Klaus Johannes Rusch [EMAIL PROTECTED] wrote: Unless the context is stored with the feed, the user experience willbe different when a user follows a link from another page (rendered asWeb page) and later loads the same link again from the bookmarks (rendered as an XML feed).If this is just an issue with the example rules, that's solvable by adapting the rules to match expectations. Maybe browsers would be willing to store some sort of context along with the bookmark. But really the underlying point is that browsers and/or feed readers can choose to render the feed however they want. The Atom syntax does not require xml-stylesheet support nor does any part of the Atom specification require that feed readers be web browsers, or that feeds be rendered as web pages. It's important to remember here that we would be in exactly in the same position if any other non-Microsoft feed reading application registered itself as the handler for the application/xhtml+xml media type. IE and Firefox would dutifully pass the file to this 3rd-party application, which probably would not be a web browser, and the feed would be rendered in a reader-specific way, with zero attention paid to xml-stylesheet. The behavior we're used to seeing is basically a fallback handler for arbitrary XML content. It's expected to be overridden when a real application steps up to say that it will handle content of that type. The IE feed reader case is somewhat distinct, but the implications are the same. The problem is that IE and Firefox's default behavior is actually useful, and a desirable alternative to applications legitimately stepping up to act as handlers for these media types. If this is what we're trying to fix, I think this is out of scope for this mailing list.From the Mozilla/Firefox perspective, you may find these bugs interesting: https://bugzilla.mozilla.org/show_bug.cgi?id=57342 - Add View as Text/HTML/... option for unknown mime content-type https://bugzilla.mozilla.org/show_bug.cgi?id=194351 - General module to show widespread XML formats: WML, RSS, DocBook, OpenOffice.org etc.The comments within the first bug also include discussion of overriding the web server's media type and/or the browser's behavior in response to it to permit content to be viewed using the browser's built-in text, HTML, or XML handling mechanisms. The discussion thus far seems to be just a variation of this, with a little automation (context) helping to make that decision. David
Re: IE7 Feed Rendering Issue
On 3/8/06, James Yenne [EMAIL PROTECTED] wrote: My counterpoint is that this is non-standard approach because the xml-stylesheet directive isa standard XML directive, and IE7 (the reader, not the browser) is essentially saying that RSS/Atom are notfirst of all XML and should be handled in some proprietary way through IE's display/navigation layer. I'm going to have to side with Microsoft on this one. When you provide information in an XML format, you're providing information, not a web page. You may desire to have it rendered a certain way when it's rendered by a web browser, but the consumers of your data can do whatever the heck they want with it. The use of xml-stylesheet is not actually part of the proper XML standard and there is no requirement that any implementation honor it. It's merely a suggestion. David--Apologies in advance if this e-mail messes with your clients. This is my first post to the list using Gmail and I'm not entirely sure how mailing-list-friendly it is.
Re: Question on Use Case: Choosing atom:content's type when ArchivingMailing Lists
On Sat, Jun 18, 2005 at 10:43:36PM -0600, Antone Roundy wrote: Not all user-agents have a MIME processor. Given the potential complexity and messiness of composite types, I'm opposed to leaving the door open for them, since they won't, I think, be needed by a significant proportion of Atom users. This brings back bad memories of But is it really necessary to FORBID using Atom for purposes that might entail using these media types? What exactly is the prohibition trying to prevent? If it's trying to prohibit anything except what the most common Atom processors are likely to understand, then we should eliminate the ability to specify arbitrary media types entirely and stick with the most common Atom uses we've already specified. If it's trying to prevent compound documents of any kind, while still allowing flexibility in selecting an appropriate single-part media type based on the application, then it needs to do that better. Currently it forbids compound media types but allows other more widely used and less widely known methods for including compound objects into the content. If it's trying simply to prevent the use of one class of media types for reasons not mentioned above, then I think it would help everyone to have that reason documented. At this point, I'm with the other posters in that this seems like an artificial constraint in the absense of more meaningful verbiage. losing data. Yes, that's just one anecdote. But it's an example of the kinds of ugliness that can spill over from one bad implementation and mess things up for everybody. Unless there's a use case that meets Perhaps a SHOULD-level requirement should be introduced to encourage implementers to avoid multipart types since they will be unlikely to be widely supported. Maybe this should be a SHOULD-level prohibition on using arbitrary media types entirely. People SHOULD stick with the text/html/xml pseudo-types we've explicitly defined unless they have a good reason to use something else. to keep things a little simpler within Atom feeds. If somebody really needs composite types, they can use an extension, and user-agent developers can decide whether to support it. This seems a little much for an extension. Specification of a piece of content is pretty fundamental to Atom. If I have to do that through an extension of my own devising, I have to wonder what I'm gaining by starting with Atom in the first place. David -- == David Nesting WL7RO Fastolfe [EMAIL PROTECTED] http://fastolfe.net/ == fastolfe.net/me/pgp-key A054 47B1 6D4C E97A D882 C41F 3065 57D9 832F AB01
Re: Fetch Me A Rock
On Thu, May 12, 2005 at 03:46:21PM -0600, Antone Roundy wrote: The problem we have, as I pointed out earlier on the thread, is that we do not specify whether senders and receivers have the same SHOULD. I made one assumption, and Rob pointed out that I had made one different than he did. So because both RFC 2119 and the current Atom draft are not explicit on this point, it is open either to varied interpretations, or at least to misinterpretations. It is therefore up to us to clarify: A summary SHOULD* be present in an entry. Implementations MUST be capable of processing entries with and without summaries (title-only feeds). This is not intended to suggest that implementations must do something useful with title-only entries. * - The implications are that many processors will ignore or reject entries that do not have summaries, because the processor may place the emphasis of its processing on the summary. The feed as a whole is still valid, however, and it's expected that processors will handle entries that DO have summaries in the same feed as entries that do NOT. David -- == David Nesting WL7RO Fastolfe [EMAIL PROTECTED] http://fastolfe.net/ == fastolfe.net/me/pgp-key A054 47B1 6D4C E97A D882 C41F 3065 57D9 832F AB01
Re: PaceFeedIdOrSelf
On Tue, May 10, 2005 at 12:05:22AM +0100, Graham wrote: rel=self is in no way a substitute for an identifier and shouldn't Has anyone considered merging these into one (required) element? The ID can be a URI. The URI need not be resolvable. If the URI is a URL, it SHOULD (MUST?) point to the feed's location. David -- == David Nesting WL7RO Fastolfe [EMAIL PROTECTED] http://fastolfe.net/ == fastolfe.net/me/pgp-key A054 47B1 6D4C E97A D882 C41F 3065 57D9 832F AB01
Re: Which is the preferred feed?
On Mon, May 09, 2005 at 10:53:14AM -0600, Antone Roundy wrote: 302 would result in feed readers (that follow the HTTP spec) continuing to hit the publisher's site every time they checked the feed, and then going to FeedBurner. I'm not sure how user agents would handle it, but one could always attach some caching headers to that 302 response to indicate that the 302 is semi-permanent. In theory, user agents could hold on to that 302 response for a little while and follow the cached redirection. David -- == David Nesting WL7RO Fastolfe [EMAIL PROTECTED] http://fastolfe.net/ == fastolfe.net/me/pgp-key A054 47B1 6D4C E97A D882 C41F 3065 57D9 832F AB01
Re: PaceFeedIdOrSelf
On Tue, May 10, 2005 at 11:52:55AM +1000, Eric Scheid wrote: Why not? the uri can change. URIs don't change; People change them.[1] But yah, things are never that simple. Consequently, ignore my other e-mail in this thread. (And sorry if this is all a re-hash.) David [1] http://www.w3.org/Provider/Style/URI.html -- == David Nesting WL7RO Fastolfe [EMAIL PROTECTED] http://fastolfe.net/ == fastolfe.net/me/pgp-key A054 47B1 6D4C E97A D882 C41F 3065 57D9 832F AB01
Re: the atom:copyright element
On Sun, May 08, 2005 at 03:18:23PM +0100, Graham wrote: What other rights can be associated with content? I intend on utilizing and publishing feeds internal to my company. While the information in the feed may be considered copyrighted, it's really my company's information classification that's the overriding piece of information that I need to attach to the feed (and/or the entries, individually). In other words, how do I attach a proprietary label to a feed or one of its entries? (Keeping in mind that I may have a proprietary summary for a resource that itself is more restrictive--say, secret.) I intended to use the copyright tag for that, because its semantics seemed closest to what I need. But now that someone else brought the issue up, I figured I'd offer my opinion. David -- == David Nesting WL7RO Fastolfe [EMAIL PROTECTED] http://fastolfe.net/ == fastolfe.net/me/pgp-key A054 47B1 6D4C E97A D882 C41F 3065 57D9 832F AB01
Re: Autodiscovery
On Tue, May 03, 2005 at 07:42:55PM +0200, Arve Bersvendsen wrote: 1) Change the attribute value for the rel from alternate to feed, or some similar wording. A feed is not always an alternate of the HTML document in which it occurs. Suggested replacement text: I'm all for avoiding pigeonholing like that. But what about the case when a feed IS an alternate version? HTML says to use alternate, this says to use feed. Which takes precedence? Plus, feed is kind of application-specific. What about related? Consider also that HTML allows alternate stylesheets to be identified with the relationships alternate and stylesheet. HTML overrides the semantics of alternate in this case (since the stylesheet isn't an alternate version of the page, it's just an alternate stylesheet). Who's to say we can't overload it a little for this case? So I might suggest, in order of preference: 1. alternate for feeds that can be considered alternate versions of the current document, and related for feeds that can be discovered via this page, but aren't actually an alternate form of the content on that page; or 2. feed for all feeds, and alternate feeds for feeds that can be considered alternate versions of the current document. (This would use alternate with its stand-alone meaning, not the meaning given to it in the alternate stylesheet case.) 2) I am not too fond of requiring a type attribute, since feeds may be served in multiple formats from a single URL. I have previously performed Omitting the type is only practical when you have a link relationship dedicated to this specific application. If we continue to use generic relationships like alternate and/or related, it becomes a little inefficient since you have to hit the link targets pretty much indiscriminately looking for one that responds with a media type you're looking for. I expect that many of my implementations will utilize content negotiation (using the same URL as an HTML representation, where needed), so I expect that I'll have some links like: link rel=alternate href=/ type=application/atom+xml link rel=alternate href=/ type=application/rss+xml Or even link rel=alternate href= type=application/atom+xml link rel=alternate href= type=application/rss+xml As crazy as that looks, is there a better way of saying this URL is also available in these media types? David -- == David Nesting WL7RO Fastolfe [EMAIL PROTECTED] http://fastolfe.net/ == fastolfe.net/me/pgp-key A054 47B1 6D4C E97A D882 C41F 3065 57D9 832F AB01
Re: Why is alternate link a MUST?
On Sun, Apr 03, 2005 at 02:45:59PM +0100, James Aylett wrote: Speaking personally, I would never have complained about it in the context of RSS because RSS is such a fragmented mess. It comes up in the context of Atom because Atom is trying to be unambiguous and helpful. This is my view as well. If MUST is vastly preferable for user agent implementors, then IMHO there should at least be an explanation of what to do when you can't generate an alternate repr I was able to locate a previous thread where this issue was discussed, but the thread appeared to peter out before this question was asked/answered. Consider for a minute these two scenarios where one might want to use Atom: 1. Where the Atom resource is the only HTTP resource representing that list of syndicated content. I MAY have an HTML version that is derived from the Atom one using XML style sheets, but I might not. That's my call. 2. Where the Atom resource itself isn't even delivered by HTTP. I may place it in a message delivered via SMTP, or in my own application protocol. Maybe I'm multicasting it to an application in my organization. I may be referencing content that *is* accessible on the web, but my actual syndication list isn't. At a minimum we need to specify what implementers must do when no alternate version exists. Even if that means specifying about:blank as the alternate URL, it should at least be documented. That way, implementations that choose to do so can at least make an educated decision about whether the value of that alternate link is meaningful or just a dummy value. If we can't or don't want to document this in the specification, maybe all we need is some unofficial, non-binding agreement now that implementations can CHOOSE to follow if they want. Maybe someone can whip up a persistent URI that can either stand for (or even deliver a message saying) no alternate exists? I suggested about:blank earlier, but maybe something delivered via HTTP (a la http://www.example.com/) might be appropriate? Maybe x-atom:no-alternate-uri? Implementations that abide solely by the specification and aren't aware or choose not to follow this convention only run the risk of allowing users to follow broken or useless links, which is exactly the situation we have today anyway. I've used RSS in some unofficial capacity in some internal applications. Maybe the regurgitated specifications I had my hands on were just incomplete or inaccurate, but none of these had any alternate link requirement. Many of my own feeds would have had alternate links with dummy values if I had been more aware of this requirement. So just because nobody complained about the artificial constraint in RSS doesn't mean the constraint is legitimate. I've found that every RSS reader or RSS consumer application handled these feeds without a problem. I should point out that the reason I am interested in Atom is to take this to the next level in my organization and actually back an IETF standard syndication format for these purposes. The RSS implementations have just been proofs of concept at this point. Thanks for your time. David -- == David Nesting WL7RO Fastolfe [EMAIL PROTECTED] http://fastolfe.net/ == fastolfe.net/me/pgp-key A054 47B1 6D4C E97A D882 C41F 3065 57D9 832F AB01
Re: Why is alternate link a MUST?
On Sun, Apr 03, 2005 at 03:06:26PM -0400, Joe Gregorio wrote: I agree with Sam, +1 to the required link. The argument that you can't have an HTML representation are weak, since *I* can generate one for your feed, whether you like it or not, ala: http://www.rss2html.com/ OK, I have Atom documents stored in the following places: 1. An attachment (or the content body) of an e-mail message 2. In an Oracle database behind a firewall 3. In an LDAP attribute, also behind a firewall 4. On a key chain hard drive 5. Typed out on a sheet of paper What URL can I use to refer to each of those? The key chain drive usually shows up as drive E:, if that helps. For simplicity, let's assume the sheet of paper can be stored on/in a flatbed scanner. I can also generate an XSLT sheet that transforms Atom into HTML then use the W3C XLST service to transform an Atom feed into HTML: http://www.w3.org/2001/05/xslt Let's say I care about providing an HTML representation for my data. XML lets me embed an XML stylesheet into the XML data itself. So now I have a completely self-contained Atom resource that user agents can transform into HTML without needing a link to any external resource. Even if this could be represented with a URI, why would I want to specify an alternate version when the first version has everything I could want? All I hear are ways *some* Atom documents can be given alternate versions. I still haven't heard WHY that should be required, other than because RSS does it. Why does RSS require it? Maybe we can start there. David -- == David Nesting WL7RO Fastolfe [EMAIL PROTECTED] http://fastolfe.net/ == fastolfe.net/me/pgp-key A054 47B1 6D4C E97A D882 C41F 3065 57D9 832F AB01
Re: Why is alternate link a MUST?
Why isn't this requirement a may instead of a must? I can see having a link with rel=alternate if indeed a alternate version does exist. It does not make sense to put in some something misleading if an alternate does not exist. I recently sought out and joined this list precisely because I wanted to see if this issue had been addressed. I don't think it's reasonable to assume there will always be an alternate version of a feed. If this remains a MUST, I have no choice but to honor this by using a dummy value for an alternate page, since I may not have an alternate. Without any background, it seems to me that the goal here is to require a link *back* to an HTML page that is presumed to have provided an alternate link to this Atom resource. This of course assumes that an HTML or non-Atom version actually exists, and that resource is independent of the Atom resource. (Consider that I may have an HTML version, but it could be derived from the Atom version using XSLT. It's not accurate to consider this an alternate when it's an XML style sheet involved.) I couldn't find any reference to this issue in the mailing list, aside from this (thankfully recent) thread. If it's been addressed before, could someone point me to the thread in the list archives? David -- == David Nesting WL7RO Fastolfe [EMAIL PROTECTED] http://fastolfe.net/ == fastolfe.net/me/pgp-key A054 47B1 6D4C E97A D882 C41F 3065 57D9 832F AB01
