Re: PaceEntryMediatype
Mark Baker wrote: The real problem here AIUI - at least in the context of HTML 5's inferred rel=feed bit - is not just entry documents, it's any Atom document which wouldn't normally be considered a feed by a typical user; something that most people would be interested in subscribing to. An example I gave on the whatwg list was an MHTML-like (MIME multipart) package, but there are many other possible examples of course; not all RFC 4287 feed documents are feeds in this sense. If HTML 5 (and current practice) doesn't change, but we defer to them for the specification of autodiscovery, then a new media type would be one way forward. But it should be reusable for all non-feed (i.e. from a user POV, as above) Atom documents, not just entry documents; perhaps application/atom-no-feed+xml. It's an ugly hack, but it's better than the alternative of many more specific Atom-related media types, which atomentry+xml might set a precedent for. Note that HTML 5's special handling of alternate+Atom is triggered on a literal value for the 'type' attribute: # If the 'alternate' keyword is used with the 'type' attribute set to the value # 'application/rss+xml' or the value 'application/atom+xml', then the user # agent must treat the link as it would if it had the 'feed' keyword specified # as well. That means rel=feed won't be implied on an Atom Entry document whether the new MIME type syntax is chosen to be application/atom.entry+xml or application/atom+xml;type=entry It also won't be implied on an Atom feed document if the syntax application/atom+xml;type=feed or application/atom+xml;type=archive is used, as was suggested earlier. This gives us a way to say link rel=alternate href=[..] type=[atom] without implying link rel=alternate feed href=[..] type=[atom] and without dropping the 'type' attribute entirely (which was the other solution pointed out on the whatwg list). ~fantasai
Re: PaceEntryMediatype
Thomas Broyer wrote: 2006/11/29, James M Snell: Create a new media type for Atom Entry Documents: application/atomentry+xml Deprecate the use of application/atom+xml for Entry Documents. I'd largely prefer augmenting the existing media type with a 'type' parameter: - application/atom+xml = either feed or entry (as defined in RFC4287) - application/atom+xml;type=feed = feed - application/atom+xml;type=entry = entry I also think this is a nicer solution. It reflects that the two document types are fundamentally the same format. If there's no practical reason to have two actually separate MIME types, I think it would make more sense to differentiate entry and feed documents like this. ~fantasai
Re: PaceAutoDiscoveryDraftIsPointless
Edward O'Connor wrote: Robert Sayre wrote: Don't move forward with the autodiscovery draft. [...] At this point there seems to be no reason for the autodiscovery draft to exist, since the WHAT-WG has ably covered the subject in Web Applications 1.0. I am worried that there are three simultaneous efforts to spec out feed autodiscovery: WA1, the RSS board's recent spec, and this draft. Ideally this stuff would get specced just once. WHAT WG seems like a neutral ground, syndication-format wise, so perhaps they're best positioned to spec feed autodiscovery in a way that makes everybody happy. +1 to speccing this through the WHAT-WG. I'm sure Ian would be happy to address any concerns brought up by this community. ~fantasai
Re: Last Call: 'The Atom Syndication Format' to Proposed Standard
Henri Sivonen wrote: On May 8, 2005, at 06:30, Walter Underwood wrote: White space is not particularly meaningful in some of these languages, so we cannot expect them to suddenly pay attention to that just so they can use Atom. Why not? We expect them not no insert other random characters there. What do the same producers do with XHTML? Opera 7.53 and Safari 1.3 render a space between the second and third Kanji in http://hsivonen.iki.fi/test/cjk-whitespace.xhtml See also Ishida's tests: http://www.w3.org/International/tests/results/white-space-ideograph Special handling of white-space in CJK context is accounted for in the CSS2.1 spec (and will be described in more detail in CSS3 Text). There will be plenty of content from other formats with this linguistically meaningless white space. Why not just get rid of it in the producer end like you have to get rid of form feeds? Because form feeds are normally not used in source code files whereas line breaks and indendation often are? ~fantasai
Re: Autodiscovery - different cases should use different rel
Nikolas 'Atrus' Coukouma wrote: fantasai wrote: Actually, I think start is the best fit. The main feed is often not a table of contents to the entire weblog, but something partial. It is, however, the starting point of the collection. Actually, I disagree with start because of the first sentence in the HTML spec: Refers to the first document in a collection of documents. This indicates that start should point to the first post in a weblog. end would be the most recent (not that end exists in the HTML spec) I think first here should not be taken as chronological, but as foremost. This would make it consistent with the second sentence: This link type tells search engines which document is considered by the author to be the starting point of the collection. This is a completely different meaning and I'm not sure why it's bundled with the first. According to this, start pointing to the homepage is fine. BTW, you might want to take a look at http://fantasai.tripod.com/qref/Appendix/LinkTypes/ltdef.html http://fantasai.tripod.com/qref/Appendix/LinkTypes/alphindex.html No offense, but with all the tripod ads, I would have much preferred a link to the Hypertext links in HTML draft [1]. Sorry. Section four is what I want. It's not indexed alphabetically and doesn't combine other documents, but it's the covers everything pretty well. [1] http://www.w3.org/MarkUp/draft-ietf-html-relrev-00.txt Not quite everything. Some of the values (like start) are not covered in that draft. ~fantasai
Re: Autodiscovery, real-world examples
Nikolas 'Atrus' Coukouma wrote: fantasai wrote: I think you've missed how things are working at the moment. Most programs implemented what's in the spec before it's written. Mark is trying to negotiate a common standard when implementations already exist. A lot of experimentation has already occurred. I'm not suggesting that the spec invalidate such well-entrenched practice, but that it allows an alternative (not requiring 'alternate') for situations in which it is not appropriate. One of the key points seems to be that autodiscovery is not meant to find all feeds linked to on a page, just the ones that serve as alternates to the current one. If people wanted this functionality, they would have done it by now. Done what? Linked to non-alternate feeds with rel=alternate just so that it would trigger autodiscovery? People do that all the time. Give them an alternative that doesn't require such a hack. I think you have three separate cases of autodiscovery: * the feed for *this* page - handled by this autodiscovery proposal * other feeds the author reads or recommends - usually done by linking to a separate file. Some quick searching reveals one suggestion to use rel=blogroll for this * any other feeds linked to for any reason at all - seems to be little interest in I don't think combining these three into one case will do any good. In fact, I think it's confusing and unusable. That makes sense. I think that you're missing one key use case, though: autodiscovery of a blog's main feed from sub-parts of it. A lot of websites link to the main blog feed from individual entries, for example, and they're doing it with rel=alternate, which is not appropriate. It frustrates me that there is no way of changing these links to not use rel=alternate. And for linking to other pages.. Here's a real-world example: The mozilla.org main page http://www.mozilla.org/ is an example of where rel=alternate is a problem. There were three feeds on it: Announcements, mozillaZine News, and Mozilla Weblogs (now only two). Each one is an alternate of a web page, but of _other_ pages (http://www.mozilla.org/news.html, http://www.mozillazine.org/, and http://planet.mozilla.org/ respectively), not the mozilla.org front page. The last few headlines for each feed are listed on the front page, and the designer felt it was appropriate for autodiscovery to work on this page -- but it is not appropriate for rel=alternate to be used for those autodiscovery links. They are not alternate representations of the front page. Here's another example: LiveJournal creates a Friends page, where it aggregates the blogs of all the users you've designated as friends. It could create an Atom feed representing this aggregation, and mark that as rel=alternate. What could also be useful, however, would be linking to each of these blogs' feeds individually as well so that they're represented individually in my aggregator and it can aggregate them itself. Unlike the pre-aggregated feed, however, these are not alternate representations of the Friends page, and shouldn't be marked as such. Making it possible for pages to link to non-alternate autodiscoverable feeds without using rel=alternate -- and encouraging this practice -- would make it possible for UAs to actually /discriminate/ between alternate and non-alternate feeds. Right now they can't, because everything is indiscriminately marked as alternate. ~fantasai
Re: Autodiscovery - different cases should use different rel
Nikolas 'Atrus' Coukouma wrote: fantasai wrote: An excellent point. Perhaps these should use rel=home :) link rel=home type=application/atom+xml href=/xml/feed.atom ... The value of rel, if present, will vary based on relation * the feed for *this* page - rel=alternate * the feed for main feed for this blog, in general - rel=home * other feeds the author reads or recommends - rel=suggested * any other feeds linked to for any reason at all - no rel, just the type and href Is this acceptable? I'm not completely happy with home and suggested because they're not specified as link types in the HTML specs [1]. Sadly, it seems the HTML authors didn't consider these cases. home seems to be an informal standard. Close matches in the HTML list are index, contents, and start. All of these are inaccurate, but I think contents is the best fit. Actually, I think start is the best fit. The main feed is often not a table of contents to the entire weblog, but something partial. It is, however, the starting point of the collection. BTW, you might want to take a look at http://fantasai.tripod.com/qref/Appendix/LinkTypes/ltdef.html http://fantasai.tripod.com/qref/Appendix/LinkTypes/alphindex.html ~fantasai
Re: Autodiscovery
Sjoerd Visscher wrote: Why not support hyperlinks too? So besides: link rel=alternate type=application/atom+xml title=Main Atom feed href=/xml/index.atom also: a rel=alternate type=application/atom+xml href=/xml/index.atomMain Atom feed/a Most webpages already have a hyperlink to the feed, so they'd only need to add two attributes. It would be a waste to have to duplicate the information in the document head. The difference between link and a is that - link applies to the document as a whole: it indicates a relationship between this document and the href destination. - a is a contextual link: it indicates a relationship between the linking context and the href destination. They have different purposes. It is imho perfectly reasonable to limit autodiscovery to links only. It is also perfectly reasonable to link to feeds with a, and expect that the UA will recognize it as a feed rather than a generic XML document. ~fantasai
Re: Autodiscovery
Phil Ringnalda wrote: Arve Bersvendsen wrote: On Tue, 03 May 2005 18:52:59 +0200, Tim Bray [EMAIL PROTECTED] wrote: http://diveintomark.org/rfc/draft-ietf-atompub-autodiscovery-01.txt 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. This would not be necessary if 'feed' were added to the HTML standard directly. 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. 'feed' is not really defining a /relation/, it's defining a sort of meta-content-type... But I would much prefer that to forcing 'alternate' on non-'alternate' links. ~fantasai (Copying to WHATWG mailing list: http://www.whatwg.org/ )
Re: Autodiscovery
Arve Bersvendsen wrote: On Wed, 04 May 2005 09:43:38 +0200, Eric Scheid [EMAIL PROTECTED] wrote: instead of feed, consider updates, which gets closer to the gist of the sense No. To me 'Updates' signifies that something is 'updated'. Even posting new content falls outside of that definition. That would signify updates to my document. If I'm linking to the CNN news feed, or my-favorite-blog, that wouldn't be appropriate. For this purpose, the syntax needs to signify that this is a feed, that it needs to be handled as such.. and that there is no other significant relationship between the document and the feed it links to (unless otherwise specified). ~fantasai
Re: Autodiscovery
Robert Sayre wrote: On 5/4/05, fantasai [EMAIL PROTECTED] wrote: Who's to say we can't overload it a little for this case? You are not writing the HTML 4.01 spec, you're writing an autodiscovery spec that takes advantage of the syntax *and semantics* given in HTML 4. Your specification should be consistent with HTML 4, not contradictory to it. The autodiscovery spec is a reasonable interpretation of the *one line* definition of the 'alternate' relation. It is not contradictory. The definition of 'alternate' is not one line long on my screen, but here's the first sentence of it: # Alternate # Designates substitute versions for the document in which the link occurs. -- http://www.w3.org/TR/REC-html40/types.html#h-6.12 How is a link from the top of my homepage to my friend's weblog feed designating a substitute version for the document in which the link occurs? Note that we are not arguing the semantics of the link element in an Atom document, but the semantics of the link element in an HTML document. ~fantasai
Re: Autodiscovery
Dan Brickley wrote: * Eric Scheid [EMAIL PROTECTED] [2005-05-05 02:35+1000] On 4/5/05 11:11 PM, Robert Sayre [EMAIL PROTECTED] wrote: The autodiscovery spec is a reasonable interpretation of the *one line* definition of the 'alternate' relation. how is a feed of recent entries a substitute version for the document in which the link occurs when that document is some blog post long since dropped out of the feed? Because the HTML definition is close to meaningless. I can substitute any document for another, and the 2nd is a substitution not through any intrinsic characteristics, but because it was substituted. Many of the HTML link type definitions don't bear up under detailed scrutiny... I think you're taking your anarchic interpretation a little too far there. Especially there: if you read the *spec*, you might notice that the definition of 'alternate' continues: # When used together with the media attribute, it implies a version # designed for a different medium (or media). From section 12.2.4, we also have # The rel attribute specifies the relationship of the linked document # with the current document. So, according to HTML 4.01 -- which is the definitive spec as far as HTML is concerned -- the following link link rel=alternate type=application/atom+xml href=feed.atom designates a link to a version of the linking document that is application/atom+xml. Again, my friend's blog feed is not an Atom version of /my/ web page; linking to it as alternate would be wrong. ~fantasai
Re: Autodiscovery
Antone Roundy wrote: On Tuesday, May 3, 2005, at 11:41 PM, fantasai wrote: David Nesting wrote: 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 That won't work, because content negotiation will continue to return the same thing it returned just now. You must somehow tell the server to return a specific other version of the current document, and you do that typically by sending a GET request with a different URL -- one that specifies a particular version of the resource. See http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14 GET /path-to-the-feed HTTP/1.1 Accept: application/atom+xml ... You don't have to change the URL--just list only the format you want in the Accept header. If the autodiscovery link was lying/mistaken and that format really isn't available at that URL, you should get a 406 (not acceptable) response. Where does it say that including a 'type' attribute on a link forces the UA to send a restricted Accept header? ~fantasai
Re: Autodiscovery
Antone Roundy wrote: On Wednesday, May 4, 2005, at 12:59 PM, fantasai wrote: Again, my friend's blog feed is not an Atom version of /my/ web page; linking to it as alternate would be wrong. To me, this raises a red flag, suggesting that using an autodiscovery link from your web page to your friend's feed is not what autodiscovery is intended for. Probably not. But the same argument applies if I have an autodiscovery link from a single entry in my blog to the main blog feed (which is a valid alternate version of my weblog's front page, but not of that single entry). ~fantasai
Re: Autodiscovery
Arve Bersvendsen wrote: On Tue, 03 May 2005 18:52:59 +0200, Tim Bray [EMAIL PROTECTED] wrote: http://diveintomark.org/rfc/draft-ietf-atompub-autodiscovery-01.txt 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. As I mentioned last November [1] I agree with not requiring the 'alternate' rel value for the reasons stated in http://fantasai.inkedblade.net/weblog/2004/linking-feeds/ Briefly, it is an abuse of its semantics because many feed links are not links to alternate representations of the current page. [1] http://www.imc.org/atom-syntax/mail-archive/msg11705.html ~fantasai
Re: Autodiscovery
David Nesting wrote: 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? Neither. You can put both. Plus, feed is kind of application-specific. What about related? A link, by its very existence, is indicating that the two documents are related. rel=related is redundant. 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). This is recognized as a mistake on the part of the HTML 4.01 spec authors. The 'rel' attribute takes a space-separated *list* of rel values: this exception aside, one value does not modify the other. Who's to say we can't overload it a little for this case? You are not writing the HTML 4.01 spec, you're writing an autodiscovery spec that takes advantage of the syntax *and semantics* given in HTML 4. Your specification should be consistent with HTML 4, not contradictory to it. ~fantasai
Re: How should this be rendered?
Anne van Kesteren wrote: Thomas Broyer wrote: (or any element using the CSS white-space property) That is purely for presentation. You should not use it if you need whitespace to be preserverd for semantics. (In such cases xml:space would probably be more appropriate...) Even if you use xml:space to make the parser preserve white space, unless the computed value of CSS 'white-space' is 'pre', a CSS renderer must collapse the white space. xml:space controls whether the parser collapses white space or not. CSS 'white-space' controls whether the white space passed from the parser to the renderer is collapsed or not. If the parser collapses whitespace, CSS will never see it. ~fantasai
Re: how to write spec language for language variants?
Eric Scheid wrote: atom:head elements MAY contain one or more atom:foo elements, so long as they differ in the values they have for the attributes atom:hreflang, xml:lang, or atom:type. I'm not comfortable with either wording. Seems clumsy. meta-question: should the spec even bother asserting this restriction? I don't think it's really necessary. ~fantasai
