Lets try that again, to everyone this time:
I think we are both on the same page. I'm glad to see that. I was suddenly beginning to feel like I had missed something somewhere as it seemed that a lot of folks were making comments that seemes off target from there normal perspective.
Regarding XML/XSLT, both client and server, in fact that is a strong area of expertise that has, as of late, become somewhat of specialized field. While the title itself is in what I would call Limbo as between Simon St. Laurent and myself we try and decide what the best direction is for the client-side XML title I have been working on (the Ajax craze kind of killed the market at all the wrong times for a client-side XML title, and the addition of Opera's XSLT support and the yet to release IE7, the timing needs to be adjusted accordingly and, for now anyway, part of what already exists may find its way into a new product effort they are working on that I dont think I can really talk about yet,... so to be safe, I probably better not.
On the other side of the fence, Kurt Cagle and I are working towards finishin out this title >
http://www.amazon.com/gp/product/159059536X/ref=pd_sbs_b_1/104-8254139-4166325?%5Fencoding=UTF8&v=glance&n=283155 < of which I can speak with a bit of confidence in suggesting that the Mozilla folks, while struggling a bit as of late, are definitely making the right decisions to ensure that the needs of their user base are best served based on the user feedback. A lot of good thing are beginning to unfold in the XML space as a whole... I think this is a good thing for all of us...
It seems like there might be a need for us to set up a separate forum or list server specific to client side browser XML processing... is there enough interest in something like this to warrant the set up? Actually, the setup takes all of about 10 minutes for the forum software I would recommend using, so if the overall interest in such a forum exists, let me know, and I will get it set up.
Thanks for helping clarify things! I feel MUCH better now!
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. 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
--
<M:D/>
M. David Peterson
http://www.xsltblog.com/
