Re: atom:updated handling
On 2/15/06, Walter Underwood [EMAIL PROTECTED] wrote: It doesn't hurt to point it out. It could catch some developer errors. But it doesn't make an invalid feed. --wunder Which is why the message you are given is found at http://feedvalidator.org/docs/warning/DuplicateUpdated.html with the accent on the */warning/*. Patches that will make that more clear are welcome. Phil Ringnalda
Re: finishing autodiscovery, like now
On 1/19/06, A. Pagaltzis [EMAIL PROTECTED] wrote: The existing behaviour is based on the various incarnations of RSS where the only document type involved are feeds. RFC 4287 introduces a new document type, the Atom Entry Document, which autodiscovery-01 fails to take into consideration. That doesn't meet my definition of well-written. I don't know how that is relevant. I am trying to think of a scenario where I'd want to autodiscover an entry document (as opposed to simply linking to it) and the inability to distinguish between feed and entry documents is causing a problem, but I can't come up with anything. Can you provide an example? I have a weblog post. I would like aggregators to discover both the feed for comments (rel=alternate feed) and the feed for my weblog (rel=feed), but I would like search engines and hypothetical Atom-aware browsers and Piggybank-style history miners to discover the Atom Entry document, where they can find just the entry for one-time fetching with no question about what they are getting (rel=alternate). Of course, if we spec only things which include feed in the rel value as being appropriate for aggregators, and all others as not, we still would need to wait three or four years for existing use of alternate alone to die down before any aggregator developer would consider following along and ignoring non-feeds. Phil Ringnalda
Re: finishing autodiscovery, like now
On 1/19/06, Joe Gregorio [EMAIL PROTECTED] wrote: Because rel is a space separated list of link types: http://www.w3.org/TR/REC-html40/struct/links.html#adef-rel https://mail.google.com/mail/ I.e. the values are all orthogonal. Though at this point in this discussion, someone is always duty-bound to point out that the only use of link that HTML actually specifies, for stylesheets, treats them as not orthogonal (alternate stylesheet is not alternate and a stylesheet, it's an alternate-stylesheet), and further assigns meaning to the presence (though not, exactly, the content) of a title attribute. Phil Ringnalda
Author of an empty feed?
The feedvalidator currently considers it an error to have a feed with zero entry elements which doesn't have an author element at the feed level. Am I missing something, or is that wrong? 4.1.1 says o atom:feed elements MUST contain one or more atom:author elements, unless all of the atom:feed element's child atom:entry elements contain at least one atom:author element. without mentioning the all none of the zero atom:entry elements case, and 4.2.1 says If an atom:entry element does not contain atom:author elements, then the atom:author elements of the contained atom:source element are considered to apply. In an Atom Feed Document, the atom:author elements of the containing atom:feed element are considered to apply to the entry if there are no atom:author elements in the locations described above. without saying anything about how atom:author at the entry level might apply to a feed. Since in the case of atom:author coming from atom:source, it doesn't (the author of a republished entry certainly isn't the author of the feed metadata), I'd claim that an empty feed shouldn't be required to have an author, since it's only needed for inheritance down to an entry. Phil Ringnalda
Re: Straw Poll: age:expires vs. dcterms:valid (was Re: Unofficial last call on draft-snell-atompub-feed-expires-04.txt)
Mark Nottingham wrote: I'm torn; on the one hand, dcterms is already defined, and already used in other feed formats; on the other hand, the syntax is less-than-simple. Indeed. A perfectly, utterly valid dcterms:valid value: start=George W. Bush; scheme=US Presidents; name=Bush II I'm -1 on using Dublin Core for anything other than providing human-readable labels for human-readable data. Phil Ringnalda
Re: Fetch me an author. Now, fetch me another author.
Robert Sayre wrote: On 5/21/05, Phil Ringnalda [EMAIL PROTECTED] wrote: Actually, no. It has one author, a corporation, or similar entity, the ATOMPUB Working Group, and two editors and many contributors. (Editorial nit: -08 says it's a product of the Network Working Group, apparently the xml2rfc default for workgroup). http://www.rfc-editor.org/rfcfaq.html 2) Every RFC is attributed to the Network Working Group. Bah. I was confused by the way some WGs list themselves while it's still an I-D, and some don't. I'll go back to my corner now. Phil Ringnalda
Re: Refresher on Updated/Modified
Tim Bray wrote: Yes, atom:modified would require that I update the date, and have the entry fetched another ten thousand times, even if I made a change that struck me as trivial. Since I'm a good citizen about specs, I would do this wasteful thing. Others would just ignore it. -Tim No, not at all. With only atom:updated, you either say everyone must re-read this or you don't. With both atom:updated and atom:modified, you can either say that, or you can say only obsessives running BrayWatcher need to notice that two letters of this have changed. At least to me, that was the whole point: I am going to replace my current RCS-based show me every trivial edit system with an Atom-based one, while still being able to tell aggregators that they don't need to bother their users when I just fix a typo. The only question is if I do it with atom:modified, which will let me also do it for my Blogger-produced feeds, where I don't control the output, and do it so other people can use it too, or if I do it with phil:modified, and it only works for me, and only with some of the tools I use to publish. Phil Ringnalda
Re: I-D ACTION:draft-ietf-atompub-autodiscovery-01.txt
On 5/10/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-atompub-autodiscovery-01.txt And a more pleasant one is: http://philringnalda.com/rfc/draft-ietf-atompub-autodiscovery-01.html or for your two words on every page? yay. pleasure: http://philringnalda.com/rfc/diff-00-01.txt Phil Ringnalda
Re: Autodiscovery in a as well as link
Nikolas 'Atrus' Coukouma wrote: Using @rel with any linking element is perfectly valid and has been for years. @rel not being supported for anything other than the link element itself has also been an outstanding bug for just as long. There's lot of debate attached to at least one Mozilla bug (#57399 [1] - filed on 2000-10-20). Can we agree that this should be supported, but currently isn't? Unless there's a compelling reason not to, I think we might as well allow autodiscovery via either element. Any implementation guide should recommend duplicating the information in the interest of autodiscovery actually working. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=57399 -1 to saying in the spec that you can use either element, and in the guide saying to use both if you want it to work, not just look pretty. As I remember it, when RSS autodiscovery started this cowpath, aggregator developers generally didn't have an SGML parser handy, and weren't especially happy about the idea of having to write their own HTML parser. Finding one (or a few) of relatively few links in the first bit of the document feels a lot easier than having to look at every a in the whole document. Now? I'd say most don't have an SGML parser handy, and won't be especially happy about writing their own HTML parser. It's fairly rare for someone to comment out bits of their head, and quite common for them to comment out huge swaths of their body, including things a template came with, like a href=../xml/index.atom rel=feedAtom feed/a, with no thought that something will be seeing and using that invisible link with an incorrect path. I added Atom autodiscovery to my current aggregator, Feed on Feeds, with a ten second copy/paste/change mime-type of the results of it using a regular expression on the HTML. If instead I had to correctly parse the entire HTML document, I'd... switch to something in Python, I guess. Then, since I foolishly took the Firefox bug for better autodiscovery, I'll also need to do it where I do have an excellent HTML parser, but I have to do it on every single page that every single Firefox user loads, whether or not they have any interest in feeds, or subscribed to the feed ten thousand loads of that particular page ago. link is easy, we've got a DOMLinkAdded event and most pages have very few of them. a? Well, the performance hit probably won't be noticeable on most pages. Phil Ringnalda
Re: Autodiscovery
Arve Bersvendsen wrote: First, I am not too fond of making an autodiscovery protocol Atom-only It's only Atom-only in that it doesn't attempt to dictate things outside the WG's charter: as it's written now, it's just a well-specified exact equivalent of the existing RSS autodiscovery spec-blog-post. Anyone who has existing code for RSS autodiscovery can simply check for one of two values of @type, rather than just one, and be done with it (well, actually, anyone with existing code for RSS autodiscovery has already long since done so). 1) Change the attribute value for the rel from alternate to feed, Don't forget, since you would be doing that primarily for people who think too much, that you'll also need to include a profile [1] URI and make a guess at what dereferencing that URI ought to return, and probably take a stab at explaining how to deal with multiple profiles, since the HTML spec punted on that. Popularizing feed would have one benefit outside Atom's scope, though: there's currently no useful way for an RSS 1.0 feed to do autodiscovery with type=application/rdf+xml since it could be any alternate RDF, not just RSS: if Atom breaks the ice with feed then RSS 1.0 wins. 2) I am not too fond of requiring a type attribute, since feeds may be served in multiple formats from a single URL. If you've changed to rel=feed you've lost all backward compatibility, so you might as well just say type=application/atom+xml and still do content negotiation for anything that actually prefers RSS: nothing that only knows RSS will recognize you (and what thing that knows Atom would prefer RSS?). But if you do rel=feed with no type, then since the namespacing aspect of @profile wasn't ever actually made workable, you are completely claiming the use of that @rel for Atom/RSS: no other past or future things could use it without being willing to take the pounding of a million aggregators. Phil Ringnalda [1] http://www.w3.org/TR/REC-html40/struct/global.html#profiles
Re: AutoDiscovery
Randy Charles Morin wrote: +1 to not Atom specific thanks Arve link title='RSS' -1 to anything that even remotely implies any significance to @title Phil Ringnalda
Re: xml:baseful test feed
Robert Sayre wrote: What would be necessary to get this feed to render on one HTML page, ala Bloglines? http://www.franklinmint.fm/2005/04/21/xmlbase.atom Running it through a competant Atom processor? http://feedparser.org/docs/resolving-relative-links.html Phil Ringnalda
Re: xml:base and html rendering
On 4/20/05, David Powell [EMAIL PROTECTED] wrote: Atom supports xml:base anywhere in the document, so different entries can have different base-URIs. HTML, however, doesn't support xml:base. This makes it difficult to display multiple entries on a HTML page. Depending on your need for correctness and elegance, you can just use the ugly hack of scattering base href=whatever elements in your output. It isn't right, but it works in every browser I've tried, and makes me happier than having relative URIs resolved relative to where my online aggregator's running. Phil Ringnalda
Re: strange Live Bookmark display of HTML version of draft in Firefox
Julian Reschke wrote: Firefox ironically displays a Live Bookmark icon for http://atompub.org/2005/04/04/draft-ietf-atompub-format-07.html :-) https://bugzilla.mozilla.org/show_bug.cgi?id=257247 I've just had a hard time pushing for draconian autodiscovery, since it's vastly easier to find broken attempts at autodiscovery links which we would still like to subscribe to than it is to find non-feeds that trigger the current lax code. Phil Ringnalda
