Re: Does xml:base apply to type=html content?
Friday, March 31, 2006, 3:31:12 AM, A. Pagaltzis wrote: In that scenario, either the tag soup from the other feeds must be fixed up so the view can be rendered as XHTML (which supports xml:base in content) XHTML 1.0 doesn't support xml:base does it? As I understand it, only specs that say that they support xml:base allow you to put xml:base on their elements, but any spec that allows URIrefs has the concept of a base-URI, so for envelope specs such as Atom, you'd expect xml:base in the envelope to set the base-URI for the content. -- Dave
Re: Does xml:base apply to type=html content?
Friday, March 31, 2006, 4:34:48 AM, you wrote: The escaped HTML content contained within the content element that David was originally concerned with is more than likely a copy of all or part of the elements and content contained inside the body tag of the external document referenced by an associated link element, and therefore no guarentee that the xml:base of the atom feed is going to be anywhere even close to accurate. That might be exactly the case where the xml:base is useful: the content came from different places, had relative URI-refs, so the xml:base was set on each entry to the source URIs of each document so that the relative links work[*] in both in cases. [*] in theory. -- Dave
Re: Does xml:base apply to type=html content?
Oh, I agree that if this can be done in a consistent manner, then using the xml:base attribute on each //entry/content element would be absolutely WONDERFUL. The trick is to figure out howtoensureaconsistentlevelofavaialability and accuracyofthevalue of eachinstanceof content/@xml:base. In thinking this trough a bit, as long as the original URI is intact, and the URI itself contains the correct URI for each resource that is referenced, then theabilityexistsviavariousmechanisminXSLT 2.0tobuildasimpletransformationfilethatcouldparseanydocument,wellformedornot,andexctractalloftheoriginalURI's,returningtheminasimpleRDFreferenceindex,tothenbeusedtodeterminewhatbaseURIshouldbeused,whichresourcesareexternal,andbuildoutthe result in a way that keeps the 404's to anabsoluteminimum. Actually, what we really need is a nice SHA1Decentralized HASH BASH weekend session to index all known resources, integrating the result string into every known file formatspecificationandensuringthataresourcealwaysknowshowtofindhiswaybacktowherehe/she/itcamefrom. Howbout'youguysbuildthatsystem,andinthemeantimeI'llwritesomequickanddirtytransformationsfilestotideusovertil'you'redone,K? I mean, what else are you gonna do after APP releases... You'll have LOADS of extra time on your hand. ;) K, Ready,set,go! On 3/31/06, David Powell [EMAIL PROTECTED] wrote: Friday, March 31, 2006, 4:34:48 AM, you wrote: The escaped HTML content contained within the content element that David was originally concerned with is more than likely a copy of all or part of the elements and content contained inside the body tag of the external document referenced by an associated link element, and therefore no guarentee that the xml:base of the atom feed is going to be anywhere even close to accurate.That might be exactly the case where the xml:base is useful: the content came from different places, had relative URI-refs, so thexml:base was set on each entry to the source URIs of each document sothat the relative links work[*] in both in cases.[*] in theory. --Dave-- M:D/M. David Petersonhttp://www.xsltblog.com/
Re: Does xml:base apply to type=html content?
hand*s*.On 3/31/06, M. David Peterson [EMAIL PROTECTED] wrote: Oh, I agree that if this can be done in a consistent manner, then using the xml:base attribute on each //entry/content element would be absolutely WONDERFUL. The trick is to figure out howtoensureaconsistentlevelofavaialability and accuracyofthevalue of eachinstanceof content/@xml:base.In thinking this trough a bit, as long as the original URI is intact, and the URI itself contains the correct URI for each resource that is referenced, then theabilityexistsviavariousmechanisminXSLT 2.0tobuildasimpletransformationfilethatcouldparseanydocument,wellformedornot,andexctractalloftheoriginalURI's,returningtheminasimpleRDFreferenceindex,tothenbeusedtodeterminewhatbaseURIshouldbeused,whichresourcesareexternal,andbuildoutthe result in a way that keeps the 404's to anabsoluteminimum. Actually, what we really need is a nice SHA1Decentralized HASH BASH weekend session to index all known resources, integrating the result string into every known file formatspecificationandensuringthataresourcealwaysknowshowtofindhiswaybacktowherehe/she/itcamefrom. Howbout'youguysbuildthatsystem,andinthemeantimeI'llwritesomequickanddirtytransformationsfilestotideusovertil'you'redone,K? I mean, what else are you gonna do after APP releases... You'll have LOADS of extra time on your hand. ;) K, Ready,set,go!On 3/31/06, David Powell [EMAIL PROTECTED] wrote: Friday, March 31, 2006, 4:34:48 AM, you wrote: The escaped HTML content contained within the content element that David was originally concerned with is more than likely a copy of all or part of the elements and content contained inside the body tag of the external document referenced by an associated link element, and therefore no guarentee that the xml:base of the atom feed is going to be anywhere even close to accurate.That might be exactly the case where the xml:base is useful: the content came from different places, had relative URI-refs, so thexml:base was set on each entry to the source URIs of each document sothat the relative links work[*] in both in cases.[*] in theory. --Dave-- M:D/M. David Peterson http://www.xsltblog.com/ -- M:D/M. David Petersonhttp://www.xsltblog.com/
RE: Does xml:base apply to type=html content?
However, exempting [EMAIL PROTECTED]'html'` content from xml:base processing won't help. Agreed and an excellent point. I guess that the end-result of this is that regardless of how one wants to interpret any of the relevant specs on this issue, a client should assume that xml:base applies to URI references in @type=html content. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of A. Pagaltzis Sent: Thursday, March 30, 2006 6:31 PM To: Atom Syntax Subject: Re: Does xml:base apply to type=html content? * Sean Lyndersay [EMAIL PROTECTED] [2006-03-31 04:00]: This is unfortunate, because HTML itself only allows base elements in the header (one per page). So if anyone wants to build a client that displays more than one item at a time using a standard HTML renderer (and most client render HTML using someone else's renderer, not their own), they have to go groveling in HTML to do URL fixup (or use iframes). That's exactly the problem currently facing Liferea. However, exempting [EMAIL PROTECTED]'html'` content from xml:base processing won't help. If the items can come from multiple feeds, such as is supported by Liferea, then mixing items from an Atom feed that uses xml:base and other feeds automatically runs into the same issue. In that scenario, either the tag soup from the other feeds must be fixed up so the view can be rendered as XHTML (which supports xml:base in content), or URL fixup needs to be done on the content from the Atom feed so it can be passed to a tag soup renderer. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
RE: Does xml:base apply to type=html content?
I haven't looked in detail at how IE does on the xml:base comformance tests, since the current beta has no support for xml:base. In light of that fact, I'm glad we failed outright instead of halfway; halfway would have been weird :). We're actually implementing xml:base support right now (and in the process, fixing the relative URL issue that Sam Ruby pointed out in our normalization format), so we'll be broken on those conformance tests for while. The fix won't make it out in the next public release, but it should make the one after that. I'll let you know how we do on those tests when the code is done. Sean -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of James Holderness Sent: Thursday, March 30, 2006 9:24 PM To: Atom Syntax Subject: Re: Does xml:base apply to type=html content? Sean Lyndersay wrote: In my own case (IE7) case, this isn't that big a deal because we have to grovel in HTML for many other reasons, but I suspect it'd be pain for other clients. Looking at the results of the Atom XmlBaseConformanceTests [1] mosts of the clients tested seemed capable of handling relative references inside HTML to some extent. Even the ones that don't necessarily pass all the tests at least get enough right to suggest that they're on the right track. IE7 is actually one of the few clients that I would consider to have failed outright. Is the latest beta any better at handling xml:base or do these problems still exist? Regards James [1] http://www.intertwingly.net/wiki/pie/XmlBaseConformanceTests
Re: Does xml:base apply to type=html content?
Friday, March 31, 2006, 11:02:18 AM, Sean Lyndersay wrote: I haven't looked in detail at how IE does on the xml:base comformance tests, since the current beta has no support for xml:base. In light of that fact, I'm glad we failed outright instead of halfway; halfway would have been weird :). We're actually implementing xml:base support right now (and in the process, fixing the relative URL issue that Sam Ruby pointed out in our normalization format), so we'll be broken on those conformance tests for while. The fix won't make it out in the next public release, but it should make the one after that. I'll let you know how we do on those tests when the code is done. Great. It would be good if you could preserve the effective base-URI of feeds and entries, so that applications using Atom extensions that contain relative URIRefs can resolve them into URIs. I suppose that it could be done by pinning an absolute xml:base onto the channel and item elements. -- Dave
Re: Does xml:base apply to type=html content?
* David Powell [EMAIL PROTECTED] [2006-03-31 09:55]: XHTML 1.0 doesn't support xml:base does it? As I understand it, only specs that say that they support xml:base allow you to put xml:base on their elements, but any spec that allows URIrefs has the concept of a base-URI, so for envelope specs such as Atom, you'd expect xml:base in the envelope to set the base-URI for the content. To be honest, I’m not sure about the precise spec interactions for this case. What I do know however is that Gecko respects xml:base in XHTML content. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Does xml:base apply to type=html content?
* M. David Peterson [EMAIL PROTECTED] [2006-03-31 07:55]: I speaking in terms of mashups... If a feed comes from one source, then I would agree... but mashups from both a syndication as well as an application standpoint are become the primary focus of EVERY major vendor. Its in this scenario that I see the problem of assuming the xml:base in current context has any value whatsoever. Pick a planet, any planet, and my point suddenly and immediattelly becomes relavent. No. That is only a problem if you just mash markup together without taking care to preserve base URIs by adding xml:base at the junction points as necessary. Copying an atom:entry from one feed to another correctly requires that you query the base URI which is in effect in the scope of the atom:entry in the source feed, and add an xml:base attribute to that effect to the copied atom:entry in the destination feed. If you do this, any xml:base attributes within the copy of the atom:entry will continue to resolve correctly. It’s much easier to get right than copying markup without violating namespace-wellformedness, even. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Does xml:base apply to type=html content?
On Mar 31, 2006, at 7:01 AM, A. Pagaltzis wrote: * M. David Peterson [EMAIL PROTECTED] [2006-03-31 07:55]: I speaking in terms of mashups... If a feed comes from one source, then I would agree... but mashups from both a syndication as well as an application standpoint are become the primary focus of EVERY major vendor. Its in this scenario that I see the problem of assuming the xml:base in current context has any value whatsoever. No. That is only a problem if you just mash markup together without taking care to preserve base URIs by adding xml:base at the junction points as necessary. Copying an atom:entry from one feed to another correctly requires that you query the base URI which is in effect in the scope of the atom:entry in the source feed, and add an xml:base attribute to that effect to the copied atom:entry in the destination feed. If you do this, any xml:base attributes within the copy of the atom:entry will continue to resolve correctly. It’s much easier to get right than copying markup without violating namespace-wellformedness, even. Exactly. When creating a mashup feed, there are any number of things that the ... masher(?) has to be careful of--for example: * Getting namespace prefixes right * Creating an atom:source element and putting the right data into it * Ensuring that all entries use the same character encoding * Ensuring that the xml:lang in context is correct * Ensuring that the xml:base in context is correct * If any of the source data isn't Atom, ensuring that all the required elements exist (...even if the source data IS Atom--you never know when you're going to aggregate from an invalid Atom feed-- then you have to decide whether to fix the entry or drop it to make your output correct) If we start assuming that mashers can't do those correctly, then we may as well not be using Atom, or even XML. If we did a proper job of specifying Atom, then we should be able to hold publishers' feet to the fire and make them get their feeds right. In Atom, xml:base is the mechanism used to determine base URIs.
Re: Does xml:base apply to type=html content?
Hey Aristotle, Firstly, thanks for your recent effort to let the foks at O'Reilly know that some serious issues have been introduced into the system since the upgrade to Movable type. I can tell you how aggravated I was to get an email from Lawrence Lessig last Saturday, which was in response to the email I sent letting him now I had made announcement regarding the stream and download... His paraphrased response was: What Post? All I get is a Page Not Found Error.Of course the reason he got this was the fact that MovableType refuses to pull their head out and realize if I update the post, that doesn't mean I want you to change the name of the html file as well!, and because i addes a few extra links and such thats exactly what took place, breaking the link I had sent him. I originally thought well maybe there simply building in a versioning system of sorts, incrementing the file name by one number with each update, but in fact thats not what they're doing at all, as its quite a random process as to what name it chooses to rename it to, often times reverting back to the original name it had it set to e.g. title_of_post_1.html will be changed to title_of_post_2.html and then back to title_of_post_1.html, or sometimes it will drop the number off entirely -- title_of_post.html -- and its all COMPLETELY random as you can make 15 updates to a post and nothing will change, and then suddenly it will decides to rename itself and break any and all link that either you sent out, or being stored on del.icio.us, or whatever else.Anyway, the point is that the reason everything is currently broken is because they moved things to a MovableType system 2 weeks ago, and in doing so its been a bit of a mess as of late. To Justin's credit though he's been fixing each and every problem as soon as that problem is made known, so if nothing else, at least theres someone both compitent and willing to do what needs to be done to keep the system running. And in fact, one of the problems (although fortunately there have been MANY, so its not as bad as it could have been) came from yours truly, as I copied over the link for the popup Free Culture reader/player, and like an idiot didnt check to see if the place that provided the copy paste code had quotes all of their attributes, and as such came to discover yesterday tha, In fact, this was the cause of breaking the feed. How can a blogging engine written in the supposed Text Processing Wonder Language, and even further, been around the game as long as anyone has, not even check for simple things like unquoted attibutes, and instead output broken XML? Okay, rant now over... :)On 3/31/06, A. Pagaltzis [EMAIL PROTECTED] wrote: No. That is only a problem if you just mash markup togetherwithout taking care to preserve base URIs by adding xml:baseat the junction points as necessary.Wellyeah...butagain,pickaplanet,anyplanet. ;) I guess thats kind of my point... Even those of us who make codeboth our life and our livelyhoodhave continued to runintotoomanyissues,and have just given up,orsimplydecidedLetsjustwaittil'AtomreleasesandthenbuildoursystemsfromtheAtomfeedsprovodide by the same folks. In fact, it seems to me that this might be the exact thing taking place, as I seem to be noticing that the overall quality has been getting better as of late. That said, I'm not sure if my concerns are founded on much of anything beyond trying to ensure that the little things that might get in the way can be cleared up and simply not be an issue any longer.As such, if all thats been proven is that my comments and base:concerns are in fact comptetely off base... ;) SWEET!!! :D Copying an atom:entry from one feed to another correctly requiresthat you query the base URI which is in effect in the scope ofthe atom:entry in the source feed, and add an xml:base attributeto that effect to the copied atom:entry in the destination feed. If you do this, any xml:base attributes within the copy of theatom:entry will continue to resolve correctly.Yeah, I can totally see that... In fact I am trying to pull together some XSLT 2.0 transform code that can be used to, in essence, canonicalize the usage of xml:base and the associated URI's, and if I can get a solid hour this morning to finish it off, then I will post the location to this thread so you all can tear it to pieces, such that we quicly develop a simple utlity that can be pushed out to the masses to build a local cache, and keep the base and relative URI pristine clean. This all relates to both the ChannelXML and AtomicRSS code that are my current areas of focus, so It's much easier to get right than copying markup withoutviolating namespace-wellformedness, even.I agree. As long as all of the proper URI's are in place, is just a matter of determining the proper base value in regards to the URI's that each will relate to, and for the most part be able to call it good. You up for PowerHack ExtremeXSLT session sometime in the next few hours? :D
Re: Does xml:base apply to type=html content?
Cool... Lets do it... I'm starting with Atom as I have already been working on a RSS to Atom transform, and it only takes 10 or so test feeds for you to realize this isn't a little 15 minute throw it together and expect it to just work type project, which by simple habit, when you have control over the source XML such that you can ensure a proper level of quality, thats definitely one of the habits that I am learning to unlearn as the once it works, its almost certain to always work just doesn't work with each of the RSS 0.XX.XXX.XX formats being thrown at you without any sort of sense of comfort that There IS an and to all of this as I coming to believe this is no longer a creature comfort I will be enjoying in the land of XSLT for quite some time ;) Let me get a few lines of code together, and send it back to this post... any and all comments, and even furthermore, testing anyone can throw at it will be GREATLY appreciated :) On 3/31/06, Antone Roundy [EMAIL PROTECTED] wrote: On Mar 31, 2006, at 7:01 AM, A. Pagaltzis wrote: * M. David Peterson [EMAIL PROTECTED] [2006-03-31 07:55]: I speaking in terms of mashups... If a feed comes from one source, then I would agree...but mashups from both a syndication as well as an application standpoint are become the primary focus of EVERY major vendor. Its in this scenario that I see the problem of assuming the xml:base in current context has any value whatsoever. No. That is only a problem if you just mash markup together without taking care to preserve base URIs by adding xml:base at the junction points as necessary. Copying an atom:entry from one feed to another correctly requires that you query the base URI which is in effect in the scope of the atom:entry in the source feed, and add an xml:base attribute to that effect to the copied atom:entry in the destination feed. If you do this, any xml:base attributes within the copy of the atom:entry will continue to resolve correctly. It's much easier to get right than copying markup without violating namespace-wellformedness, even.Exactly.When creating a mashup feed, there are any number of thingsthat the ... masher(?) has to be careful of--for example:* Getting namespace prefixes right * Creating an atom:source element and putting the right data into it* Ensuring that all entries use the same character encoding* Ensuring that the xml:lang in context is correct* Ensuring that the xml:base in context is correct * If any of the source data isn't Atom, ensuring that all therequired elements exist (...even if the source data IS Atom--younever know when you're going to aggregate from an invalid Atom feed--then you have to decide whether to fix the entry or drop it to make your output correct)If we start assuming that mashers can't do those correctly, then wemay as well not be using Atom, or even XML.If we did a proper jobof specifying Atom, then we should be able to hold publishers' feet to the fire and make them get their feeds right.In Atom, xml:baseis the mechanism used to determine base URIs.-- M:D/M. David Peterson http://www.xsltblog.com/
Re: Does xml:base apply to type=html content?
On Mar 30, 2006, at 9:20 PM, James M Snell wrote: I would agree that, as a best practice, the xml:base should appear on the content element, but implementations need to be prepared to use whatever the in-scope URI is (e.g. if no xml:base is specified, relative refs in the content will be relative to Content-Location or the feeds Request URI). Maybe. Highly error-prone. In other words, consumers of the feed *have* to assume that the current xml:base in context is going to be correct and publishers of the feed simply have to be responsible for Doing The Right Thing. Agreed. I think providing an xml:base in your feed is a best practice. -Tim
Re: Does xml:base apply to type=html content?
Good enough for me :) (although, I had already been convinced of this by the rest of you as well)On 3/31/06, Tim Bray [EMAIL PROTECTED] wrote:On Mar 30, 2006, at 9:20 PM, James M Snell wrote: I would agree that, as a best practice, the xml:base should appear on the content element, but implementations need to be prepared to use whatever the in-scope URI is (e.g. if no xml:base is specified, relative refs in the content will be relative to Content-Location or the feeds Request URI).Maybe.Highly error-prone. In other words, consumers of the feed *have* to assume that the current xml:base in context is going to be correct and publishers of the feed simply have to be responsible for Doing The Right Thing.Agreed.I think providing an xml:base in your feed is a best practice. -Tim-- M:D/M. David Petersonhttp://www.xsltblog.com/
Re: Does xml:base apply to type=html content?
On Mar 30, 2006, at 10:30 PM, James M Snell wrote: Antone Roundy wrote: [snip] 2) If you're consuming Atom and you encounter a relative URI, how should you choose the appropriate base URI with which to resolve it? I think there are only three remotely possible answers to #2: xml:base (including the URI from which the feed was retrieved if xml:base isn't explicitly defined), the URI of the self link, and the URI of the alternate link. Given that Atom explicitly supports xml:base, if it's explicitly defined, it's difficult to justify ignoring it in favor of anything else. There is no basis in any of the specs for using the URI of the self or alternate link as a base uri for resolving relative references in the content. The process for resolving relative references is very clearly defined. Right--my point is: 1) If the original publisher made the mistake of using relative references without explicitly setting xml:base (figuring that consumers could resolve the references relative to the location of the feed), and then the feed got moved or mirrored, one would certainly fail at finding the things the publisher intended to point to if the URI from which the feed was retrieved was used as the base URI, but might succeed by using the self link as the base URI. (I do not advocate doing this as default behavior, as stated below). 2) If the original publisher made the mistake of not even thinking about relative references in the content and therefore didn't set xml:base, the relative references may very well be relative to the location pointed to by the alternate link. For example, the person generating the content may have been thinking my blog entry will appear at http://example.org/blog/2006/03/foo.html, so I can use the relative URL ../../../img/button.gif to point to the image at http://example.org/img/button.gif;. If the alternate link points to http://example.org/blog/2006/03/foo.html, then the consumer that wants to find the image will only succeed by using the alternate link as the base URI. (I do not advocate doing this as default behavior, as stated below). Moral of this story: failing to explicitly set xml:base is bad because it tempts consumers to ignore the spec in order to get what they want. I do not advocate ignoring the spec as default behavior. But honestly, I might give the user of a consuming application the option of overriding the default behavior on specific feeds if they know that the publisher makes the mistake of publishing links relative to the self or alternate link without setting xml:base. I'd LIKE to be able to hold the publisher's feet to the fire and make them fix the feed, but sometimes my users hold MY feet to the fire and make me give them usable workarounds. Antone
Re: Does xml:base apply to type=html content?
Quoting A. Pagaltzis [EMAIL PROTECTED]: * David Powell [EMAIL PROTECTED] [2006-03-31 09:55]: XHTML 1.0 doesn't support xml:base does it? As I understand it, only specs that say that they support xml:base allow you to put xml:base on their elements, but any spec that allows URIrefs has the concept of a base-URI, so for envelope specs such as Atom, you'd expect xml:base in the envelope to set the base-URI for the content. To be honest, I’m not sure about the precise spec interactions for this case. What I do know however is that Gecko respects xml:base in XHTML content. Opera 9 weeklies should do the same... -- Anne van Kesteren http://annevankesteren.nl/
Re: Does xml:base apply to type=html content?
Tim Bray wrote: On Mar 30, 2006, at 9:20 PM, James M Snell wrote: I would agree that, as a best practice, the xml:base should appear on the content element, but implementations need to be prepared to use whatever the in-scope URI is (e.g. if no xml:base is specified, relative refs in the content will be relative to Content-Location or the feeds Request URI). Maybe. Highly error-prone. Not sure what you mean by highly error-prone, but I do know that support for Content-Location in aggregators is essentially non-existent. I've run tests on 16 different aggregators and Snarfer was the only one that supported Content-Location as a base URI. Thunderbird was the next best in that it made use of the Location header when there was a redirect. A couple of others at least used the request URI. However the rest either used the feed alternate link, the element alternate link or the server hostname. Two didn't seem to support relative URIs at all. Aggregators tested: Blogbridge, Bloglines, BottomFeeder, FeedDemon, FeedReader, Google Reader, GreatNews, JetBrains Omea, Netvibes, Newsgator Online, NewzCrawler, RSSBandit, RSSOwl, Sharpreader, Snarfer, and Thunderbird. I also understand there is some debate whether supporting Content-Location is a good idea at all (at least in web browsers). Firefox at one point started adding support, but they determined that it caused problems with broken servers (mostly IIS I believe). I know there was some discussion about doing server detection and working around those servers, but some other issue came up that made them give up the whole idea (I can't remember what). I'm not sure whether any of these issues apply to feed readers. Regards James
xml:base in your Atom feed
Sam, Funny that this should come up today given the recent discussion on the mailing list--NetNewsWire isn't getting the links in your Atom feed right. I looked at the source, and it's clearly a NetNewsWire bug since it's not even trying to resolve relative to the URI from which it retrieves the feed. In fact it appears to be resolving relative to the alternate link (link href=/blog//), and not doing such a good job of it--for example, instead of http:// www.intertwingly.net/blog/2006/03/31/Rogers-Switches, it's pointing to http:/blog/blog/2006/03/31/Rogers-Switches--but I wonder whether it would get it right if you set xml:base explicitly. Antone
Re: xml:base in your Atom feed
Antone Roundy wrote: Sam, Funny that this should come up today given the recent discussion on the mailing list--NetNewsWire isn't getting the links in your Atom feed right. There is an off chance that I have been following the list. ;-) - Sam Ruby
Re: xml:base in your Atom feed
On Mar 31, 2006, at 4:12 PM, Sam Ruby wrote: Antone Roundy wrote: Sam, Funny that this should come up today given the recent discussion on the mailing list--NetNewsWire isn't getting the links in your Atom feed right. There is an off chance that I have been following the list. ;-) I certainly didn't mean to imply that you weren't--I just wanted to point out what I'm seeing in case you didn't know that this particular feed reader is having this particular problem today. And I thought it might be of interest to the WG to know what NNW is doing given that it's doing something that has been argued against within the last 24 hours. I don't remember which version of your feed I was subscribed to before--perhaps I wasn't subscribed to the Atom feed and NNW updated my subscription when you redirected to it. So I don't know whether you purposely removed xml:base to see what chaos would ensue, or whether it hasn't been there all along and I just haven't seen the problem since I was subscribed to a different version.
Re: xml:base in your Atom feed
Antone Roundy wrote: On Mar 31, 2006, at 4:12 PM, Sam Ruby wrote: Antone Roundy wrote: Sam, Funny that this should come up today given the recent discussion on the mailing list--NetNewsWire isn't getting the links in your Atom feed right. There is an off chance that I have been following the list. ;-) I certainly didn't mean to imply that you weren't--I just wanted to point out what I'm seeing in case you didn't know that this particular feed reader is having this particular problem today. And I thought it might be of interest to the WG to know what NNW is doing given that it's doing something that has been argued against within the last 24 hours. ;-) I don't remember which version of your feed I was subscribed to before--perhaps I wasn't subscribed to the Atom feed and NNW updated my subscription when you redirected to it. So I don't know whether you purposely removed xml:base to see what chaos would ensue, or whether it hasn't been there all along and I just haven't seen the problem since I was subscribed to a different version. As late as this morning, all link/@href attributes in my Atom feed contained absolute URIs. One of the original problems that Atom set out to solve was the desire by people to use relative URIs. Even in their content. In fact, PARTICULARLY in their content. My recent post of Common Feed Errors demonstrate that this demand certainly exists - even in RSS: http://www.intertwingly.net/blog/2006/03/13/Common-Feed-Errors It would be helpful if people were to update: http://intertwingly.net/wiki/pie/XmlBaseConformanceTests - Sam Ruby
Re: xml:base in your Atom feed
and here I was holding this inside of me as I always assumed obviously it's implemented for a reason This makes me happy :) Thanks Sam! On 3/31/06, Sam Ruby [EMAIL PROTECTED] wrote: Antone Roundy wrote: On Mar 31, 2006, at 4:12 PM, Sam Ruby wrote: Antone Roundy wrote: Sam, Funny that this should come up today given the recent discussion on the mailing list--NetNewsWire isn't getting the links in your Atom feed right. There is an off chance that I have been following the list. ;-) I certainly didn't mean to imply that you weren't--I just wanted to point out what I'm seeing in case you didn't know that this particular feed reader is having this particular problem today. And I thought it might be of interest to the WG to know what NNW is doing given that it's doing something that has been argued against within the last 24 hours. ;-) I don't remember which version of your feed I was subscribed to before--perhaps I wasn't subscribed to the Atom feed and NNW updated my subscription when you redirected to it. So I don't know whether you purposely removed xml:base to see what chaos would ensue, or whether it hasn't been there all along and I just haven't seen the problem since I was subscribed to a different version. As late as this morning, all link/@href attributes in my Atom feed contained absolute URIs. One of the original problems that Atom set out to solve was the desire by people to use relative URIs. Even in their content. In fact, PARTICULARLY in their content. My recent post of Common Feed Errors demonstrate that this demand certainly exists - even in RSS: http://www.intertwingly.net/blog/2006/03/13/Common-Feed-Errors It would be helpful if people were to update: http://intertwingly.net/wiki/pie/XmlBaseConformanceTests - Sam Ruby -- M:D/ M. David Peterson http://www.xsltblog.com/
Re: xml:base in your Atom feed
* Sam Ruby [EMAIL PROTECTED] [2006-04-01 01:50]: It would be helpful if people were to update: http://intertwingly.net/wiki/pie/XmlBaseConformanceTests For that matter, I’ve been meaning to address some weaknesses in that test suite which Liferea 1.0 highlights. Liferea does URI fixup for Atom links in its feed parser, but merely uses the entry’s alternate URI as the base URI when rendering content. So it succeeds legitimately on cases that test things like atom:link, but then accidentally succeeds on a number of cases that involve atom:content where it should be failing. I’ve been meaning to add some aggressive tests which use xml:base values that differ drastically from the nearby alternate URIs in order to smoke out such coincidentally passing tests, as well as some intentionally evil tests with `type=xhtml` where xml:base is set on elements inside the xhtml:div. I expect to see a lot of aggregators fall from grace with such an expanded test suite. Sam: is it possible to host the test suites directly on the wiki, by having pages that consist entirely of verbatim text? Ideally, the content should be rendered inside the wiki chrome using `pre` tags, but be downloadable without the chome by way of adding something like `?display=raw;type=application/atom+xml` to the page URI. That would make it much easier for more people to pitch in. I find the collection of tests we have so worryingly minimal; a lot of the currently lesser used corners of the format are not being tested at all. It makes me nervous that dirty data based on current incomplete implementation behaviour may become too widespread for aggregator developers to be able to ignore it. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: xml:base in your Atom feed
A. Pagaltzis wrote:
Sam: is it possible to host the test suites directly on the wiki,
by having pages that consist entirely of verbatim text? Ideally,
the content should be rendered inside the wiki chrome using
`pre` tags, but be downloadable without the chome by way of
adding something like `?display=raw;type=application/atom+xml`
At the moment, the raw text can be obtained with ?action=raw
Of course, that means that the non raw text might look a little weird.
I am comfortable enough with the moin code base that I would be willing
to code up a specific action just for this wiki that strips leading {{{
and trailing }}} and then delivers the results raw, with the appropriate
mime type.
How does ?action=atomtest sound?
- Sam Ruby
Re: xml:base in your Atom feed
* M. David Peterson [EMAIL PROTECTED] [2006-04-01 03:15]: Obviously the main wiki would be better, but if this can act as a backup plan, then let me know if and when and I will set up access to that box for you. Hosting is not the point. I have webspace and I can link files I host from the main wiki, as before. Collaboration is the point. I’m hoping for a way for anyone to pitch in without having to fight any red tape, so that the test suite can be expanded by whoever happens to have a spare tuit. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: xml:base in your Atom feed
* Sam Ruby [EMAIL PROTECTED] [2006-04-01 03:40]:
I am comfortable enough with the moin code base that I would be
willing to code up a specific action just for this wiki that
strips leading {{{ and trailing }}} and then delivers the
results raw, with the appropriate mime type.
Sounds good.
How does ?action=atomtest sound?
Maybe `action=atom`?
Regards,
--
Aristotle Pagaltzis // http://plasmasturm.org/
Re: xml:base in your Atom feed
A. Pagaltzis wrote: I’ve been meaning to add some aggressive tests which use xml:base values that differ drastically from the nearby alternate URIs in order to smoke out such coincidentally passing tests, as well as some intentionally evil tests with `type=xhtml` where xml:base is set on elements inside the xhtml:div. I expect to see a lot of aggregators fall from grace with such an expanded test suite. Yep. I've run tests like that. Haven't found a single aggregator (including my own) that handled xml:base on the xhtml:div or deeper. I find the collection of tests we have so worryingly minimal; a lot of the currently lesser used corners of the format are not being tested at all. Agreed. For various political reasons I don't want to get involved with test creation, but I do contribute results when I get a chance (I suspect more than half the xml:base results were added by me). I think you might get more involvement if the tests were easier to use though. By that I mean tests that say exactly how they should be interpreted and that you can see at a glance whether you've got a pass or failure. Having to click through links to see if they are valid can get a bit tiresome when you've trying to evaluate 16 tests on 20 different aggregators. Regards James
Re: xml:base in your Atom feed
Eric Scheid wrote: On 1/4/06 12:24 PM, James Holderness [EMAIL PROTECTED] wrote: one way would be to use img / instead of a / links, with each test image being specific to the test ... that way all one needs to do is read the feed and check to see if the text in the image corresponds to the text in the entry headline. Especially easy if the tests were numbered. My thoughts exactly. You can see an example in one of my base tests here: http://216.93.169.119/atomtests/base/base4.atom That test is a lot more complicated than need be for a conformance tests since it's more informative than simply testing pass/failure, but it demonstrates the concept. And the bit about numbering is also something I forgot to mention previously. Many aggregators will reorder the results of a feed in ways that might not be expected. By clearly numbering every test you can avoid any confusion when it comes to matching the results from the feed back to the wiki page. Regards James
