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 page
2. 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
