Re: PaceOptionalSummary
Antone Roundy wrote: +1. ...oh, and the wording I just suggested for part of PaceTextShouldBeProvided would depend on this also being accepted. With deep regret, I'm going to express my -1 on PaceOptionalSummary. Not because I object to the text expressed in the proposal section. In fact, I clearly do not as I lifted large sections of it to be placed into PaceTextShouldBeProvided. No, it is because the author of PaceOptionalSummary has made it clear that he interprets the two paces to be incompatible, so each and every +1 for PaceOptionalSummary is a vote against PaceTextShouldNotBeProvided. Despite wording that accompanied several of these +1's, like the wording describe above. I also feel the need to express deep dismay at the way that author of PaceOptionalSummary has been pursuing a scorched earth approach whereby everybody who expresses an opinion to the contrary is viciously attacked for doing so. I believe that this has significantly hampered the ability of the work group to hold a reasonable discourse on the subject. Despite this, I have attempted to see if there was some common ground to be found. I drafted up a Pace, and offered a few suggestions. It has since become clear to me that PaceOptionalSummary is being pursued in a winner take all manner. As such, I see no other path than to offer my -1 on the Pace. Face down, arms and legs outstretched, in the middle of the road. One thing I would like those who advocate PaceOptionalSummary to the exclusion of all other Paces on the subject to consider... what happens if the chairs determine that consensus can't be found on either of these paces? Look at the current wording of draft-08. Is that what you really want? We can do better. - Sam Ruby
Re: PaceOptionalSummary
On 9 May 2005, at 1:19 pm, Sam Ruby wrote: I also feel the need to express deep dismay at the way that author of PaceOptionalSummary has been pursuing a scorched earth approach whereby everybody who expresses an opinion to the contrary is viciously attacked for doing so. I believe that this has significantly hampered the ability of the work group to hold a reasonable discourse on the subject. Plus fucking one. As such, I see no other path than to offer my -1 on the Pace. Face down, arms and legs outstretched, in the middle of the road. -1 also. Graham
Re: Last Call: 'The Atom Syndication Format' to Proposed Standard
A. Pagaltzis wrote: * Thomas Broyer [EMAIL PROTECTED] [2005-05-03 19:35]: This means type=text content is a single paragraph of text. If you need paragraphs, lists or any other structural formatting, you have to use type=html or type=xhtml with the appropriate content. Or type=text/plain, Id assume? If you're talking about atom:content, not for Text Constructs. -- Thomas Broyer
PaceNoAlternateForFeed
http://www.intertwingly.net/wiki/pie/PaceNoAlternateForFeed
== Abstract ==
Allow publishers to indicate when they have no alternate link for a feed.
Author: BillDehora
== Status ==
Open
Incept: 2005-05-09
Written against:
http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-08.txt
== Rationale ==
Not all publishers have a suitable alternate link for a feed. Example
cases include subversion repositories [1], and mail archives [2].
== Proposal ==
In section 4.1.1 change the tenth bullet point
{{{
o atom:feed elements MUST contain at least one atom:link element
with a relation of alternate.
}}}
to
{{{
o atom:feed elements MUST contain either and cannot contain both
- one or more atom:link elements with a relation of alternate.
- one and only one atom:link element with a relation of
no-alternate.
}}}
== Impacts ==
* PaceFeedIdOrAlternate: none, that pace is withdrawn.
* PaceFeedIdOrSelf: that pace suggests pointing to self in the absence
of an atom:[EMAIL PROTECTED]'alternate'] or an atom:id. This pace suggests
allowing the publisher to state there is no alternate.
== Notes ==
Fragment example derived from 1.1 example 2 in draft-08
{{{
feed xmlns=http://purl.org/atom/ns#draft-ietf-atompub-format-08;
title type=textdive into mark/title
subtitle type=html
A lt;emgt;lotlt;/emgt; of effort
went into making this effortless
/subtitle
updated2005-04-02T12:29:29Z/updated
idtag:example.org,2003:3/id
link rel=no-alternate /
copyrightCopyright (c) 2003, Mark Pilgrim/copyright
}}}
* The author is not attached to the token 'no-alternate'. Any other
token is fine once we agree that it states the publisher is saying there
is no alternate link for this feed.
* The author is fine with a SHOULD provide rather than MUST provide.
* Whether atom:feed/atom:id MUST be present in the absence of an
alternate be present can be argued about separately from whether there
is no alternate. see PaceFeedIdOrSelf.
cheers
Bill
[1] http://www.imc.org/atom-syntax/mail-archive/msg13995.html
[2] http://www.imc.org/atom-syntax/mail-archive/msg13978.html
PaceFeedIdOrSelf
The pace adds this under atom:feed: atom:feed elements that contain no child atom:id element MUST contain an atom:link element with a relation of self. That could just as well be: atom:feed elements that contain no child atom:link element with a relation of self MUST contain an atom:id element. Each subtly implies a preference for one or the other. I prefer the second--a preference for an element that can't be spoofed (or where spoofing can easily be detected). If that's missing (as in cases like SMTP delivery that have been noted, where the feed isn't retrievable from a specific URI), then atom:id must be added to provide a way to identify the feed. I didn't change the Pace, since such a change could conceivably change the opinions of people who've expressed an opinion on it already. But I would be interested to know whether people think this would be an improvement, make it worse, or if either is just as well. As for 'atom:feed elements SHOULD contain at least one atom:link element with a relation of alternate.', I don't care particularly whether this is SHOULD or MAY, just not MUST. So if another Pace makes this a MAY, I as the author of PaceFeedIdOrSelf, would not consider it to conflict (on that point, at least) with PaceFeedIdOrSelf.
Re: PaceNoAlternateForFeed
Bill de hÓra wrote:
...
{{{
o atom:feed elements MUST contain either and cannot contain both
- one or more atom:link elements with a relation of alternate.
- one and only one atom:link element with a relation of
no-alternate.
}}}
...
link rel=no-alternate /
...
Is this meant to be a serious proposal? Why can't ve just leave a
protocol element out if we don't have information for it???
Best regards,
Julian
Re: PaceNoAlternateForFeed
Bill de hÓra wrote: ... Currently you MUST provide an alternate feed link. People are saying they don't always have one to provide, which encourages garbage out. That satisfying a spec constraint for its own sake. This addition allows someone to say there is no alternate for this link. It's less ambiguous than not providing an alternate and more useful than providing junk links. Not present is not the same as not the case. ... How is it less ambiguous if the spec states that the absence of the link means that there is no alternate information? Best regards, Julian
Re: PaceTextShouldBeProvided
On 5/6/05, Bill de hÓra [EMAIL PROTECTED] wrote: -1. I agree with Robert; it conflicts with PaceOptionalSummary and I doubt it would exist if PaceOptionalSummary had not make the cut. -1 as well. Doesn't solve a technical problem. It's just gamesmanship. Robert Sayre
Which is the preferred feed?
Some sites are beginning to serve their feeds via intermediaries like FeedBurner. They are doing this, in part, to make it easier for them to get better statistics on their use of the feeds, to off-load bandwidth requirements, or to take advantage of the advertising insertion and management programs of the intermediaries. However, many of todays intermediaries require that program participants manage a base feed on their own sites that is later copied to the intermediary. This is the approach taken by FeedBurner among others. Whether or not the intermediaries require that a feed be maintained on the site, this is usually required if only because there will be people who are reading the feed and there is no means to notify them, within the feed, that a new preferred source of the feeds is available. For instance, the Typepad site blog.deeje.tv has two feeds generated by Typepad: http://blog.deeje.tv/musings/atom.xml http://blog.deeje.tv/musings/index.rdf and it has a feed generated by FeedBurner: http://feeds.feedburner.com/deeje/musings Now, my assumption is that the owner of blog.deeje.tv probably would prefer that people read his FeedBurner feed rather than the TypePad feeds. Evidence of this can be seen in that the autodiscovery links on the page point to the FeedBurner feeds. However, while the links currently point to FeedBurner, they have not always pointed there At some point in the past, the owner of this blog decided to prefer the FeedBurner service over Typepad for feed services. At some point in the future, the same owner might wish to drop the FeedBurner service in favor of some other service or perhaps just go back to Typepad normal feeds. The problem, of course, is that there is no existing mechanism by which these changes in preferred feeds can be indicated in either an Atom or RSS file. The result is that any software system that started reading the Atom or RDF feeds provided by Typepad before this blog started using FeedBurner will continue to read the Typepad feeds in the future. Similarly, any system currently reading the FeedBurner feeds is likely to continue reading those feeds in the future. One could argue that feed reading software should, on some regular schedule, re-scan the alternate site for a feed to see if the autodiscovery links have changed. However, this is a pretty crude solution It would be much, much better to allow a feed to contain data that explicitly identifies a preferred alternative source. Supporting a means to identify a preferred alternative source would greatly improve the mobility of feeds across the network and would avoid the current problem of potentially pinning someone down to a feed delivery service simply because of historical accident. If I want to move my feeds from Typepad to FeedBurner, I should be able to without having to worry about leaving behind everyone who had ever started reading my Typepad feeds. Similarly, if I later decide that I want to move off FeedBurner, there should be a way to point people to the location of my preferred feeds. bob wyman
Re: Which is the preferred feed?
Bob Wyman wrote: Some sites are beginning to serve their feeds via intermediaries like FeedBurner. They are doing this, in part, to make it easier for them to get better statistics on their use of the feeds, to off-load bandwidth requirements, or to take advantage of the advertising insertion and management programs of the intermediaries. Sites could also use a HTTP 302 link on their own site that points to FeedBurner in the end. When FeedBurner dies or when they no longer have desire to use the service, they switch the location of the temporary redirect and all is fine. -- Anne van Kesteren http://annevankesteren.nl/
Re: PaceOptionalFeedLink
On 5/6/05, Martin Duerst [EMAIL PROTECTED] wrote: At 11:50 05/05/06, Sam Ruby wrote: Tim Bray wrote: +1 There are people who want to publish feeds without rel=alternate links. I'm against telling people they can't do something they want to do without strong reasons, as in loss of interoperability. I don't see the reasons here as strong enough. -Tim +1 as well. In this case, the problems faced by producers seem to outweigh those faced by consumers. The link doesn't seem to be helpful as an identifier, so that's orthogonal. Robert Sayre
Re: Which is the preferred feed?
On Monday, May 9, 2005, at 10:27 AM, Anne van Kesteren wrote: Bob Wyman wrote: Some sites are beginning to serve their feeds via intermediaries like FeedBurner. They are doing this, in part, to make it easier for them to get better statistics on their use of the feeds, to off-load bandwidth requirements, or to take advantage of the advertising insertion and management programs of the intermediaries. Sites could also use a HTTP 302 link on their own site that points to FeedBurner in the end. When FeedBurner dies or when they no longer have desire to use the service, they switch the location of the temporary redirect and all is fine. This method would have a few weaknesses: 1) From http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10: 10.3.3 302 Found The requested resource resides temporarily under a different URI. Since the redirection might be altered on occasion, the client SHOULD continue to use the Request-URI for future requests. 302 would result in feed readers (that follow the HTTP spec) continuing to hit the publisher's site every time they checked the feed, and then going to FeedBurner. 2) Not everyone is going to be able to send a 302. A 301 would solve the first problem, but replace it with a worse one--there would be no way to indicate a new location to people once they were subscribed to the FeedBurner feed if it were to move again. One solution that might work would be to set the self link to the preferred address. That wouldn't provide a way to indicate a preferred format though, if that's part of what's desired. If all formats are being served from the same address using content negotiation, then that doesn't matter. And if they're being served from different addresses, then each feed can point it's self link to the preferred address for that format. Are there any issues that couldn't be solved by that method?
Re: Which is the preferred feed?
Antone Roundy wrote: 302 would result in feed readers (that follow the HTTP spec) continuing to hit the publisher's site every time they checked the feed, and then going to FeedBurner. As it would not be a very large hit of say, 25 to 50 KiB; I guess people can live with that. 2) Not everyone is going to be able to send a 302. Not everyone is going to be able to send 410 either. Not everyone is going to be able to say that the MIME type is application/atom+xml (yes, I'm aware about the deal with Apache and Microsoft). Et cetera. -- Anne van Kesteren http://annevankesteren.nl/
Re: PaceNoAlternateForFeed
On May 9, 2005, at 8:13 AM, Bill de hÓra wrote: Why can't ve just leave a protocol element out if we don't have information for it??? Because it allows someone to assert there is no alternate link for their feed. That's different from leaving an alternate link out. What observable difference in the behavior of software would be affected by this difference? It's not obvious to me that there's a meaningful difference. -Tim
RE: Which is the preferred feed?
Anne van Kesteren wrote: Sites could also use a HTTP 302 link on their own site that points to FeedBurner in the end. When FeedBurner dies or when they no longer have desire to use the service, they switch the location of the temporary redirect and all is fine. While 302 is an obvious technical solution, it just doesn't do the job. HTTP's 302 is just a bit too absolute... For instance, if I'm trying to push people from my Atom 0.3 feed to my Atom V1.0 feed, it is likely that there will be many readers who don't know how to process Atom V1.0 correctly -- at least initially. They should be free to fallback to the Atom 0.3 feed until they learn the new format. Similarly, if I have readers who use one of the MAC based readers that only read RSS, it becomes problematic to force them to read my Atom V1.0 feeds... It should also be noted that the ability to change HTTP response codes is not something which is typically provided to many bloggers today. I'm aware of no blog hosting services that allow for customer-requested 302 status values. Even on the one-user systems, I think its pretty hard for normal folk to figure out how to make the modifications needed to return a 302 for some files. We should also realize that business issues are likely to make it difficult for people to use 302-based solutions. For instance, a site that provided intermediary feed serving might not wish to make it easy for people to migrate their feeds away from their service. They might *like* the idea that switching costs are very high... Thus, they might simply refuse (on some technical grounds) to allow users who are moving to a new service to get 302-forwarding on their feeds. On the other hand, if the Atom format itself contained a means of redirecting to preferred feeds, and if the spec said that such data MUST NOT be removed when a feed is copied, etc., then one could essentially force vendors to support feed mobility. (Yes, there would be loop-holes) Normally, I wouldn't argue for replicating an HTTP feature inside the feeds, however, I think that what I'm talking about here is not really what 302 was intended to provide. In any case, this may be looked at as a layering issue. 302 provides hard redirection at the HTTP level, a preferred feed indicator provides soft-redirection at the application level. Implementation of similar services in multiple layers of the stack is a reasonable thing to do as long as the semantics vary at least slightly between the layers and the reasons for the variances are related to the nature of the layers. bob wyman
On SHOULD
Off-list, I've been told some it would help to explain my view that PaceTextShouldBeProvided and PaceOptionalSummary are incompatible. --- First, remember that PaceOptionalSummary does one thing--make content/summary optional. This means that Atom Processors MUST be prepared to interoperate with title-only feeds. It doesn't mean an _application_ has to accept them. It does mean that application authors can't claim it breaks their Atom machinery. We don't care what applications do after something is parsed. They can turn everything purple and display it with polar coordinates. Let's start with the current draft's requirements: 1 of atom:content or atom:summary MUST be present. That's clear. It means that say, Jakarta FeedParser, could halt and catch fire if it encountered an atom:entry missing both elements. PaceOptionalSummary dismissed the requirement entirely, as its only action. Jakarta FeedParser would have to be prepared to deal with title-only feeds. --- Here's where SHOULD comes in. We're lucky that we have an example of what happens when a SHOULD is violated. I'm sure most of you saw the nasty arguments, accusations, and all-around busted software that happen this week with Google Web Accelerator and Ruby On Rails.[0] Ugly, right? This WG should be proud that we've kept the SHOULDs to a minimum. PaceTextShouldBeProvided proposes a number of (IMO) misguided a requirements in effort to reverse the effect of PaceOptionalSummary. It proposes that summary/summary is threat to interop while summary /summary is not. It makes similar claims for a number of other situations. It does reasonably propose that application-specific atom:content SHOULD have an accompanying summary. Lastly, it makes this requirement: 1 of atom:content or atom:summary SHOULD be present. It means that say, Jakarta FeedParser, could halt and catch fire if it encountered an atom:entry missing both elements and remain conformant. It does allow for the possibility of a parser that can handle it. That's not what PaceOptionalSummary proposed. The discussion has heard from application authors and publishers who value the ability to choose title-only feeds. That choice *does not* cause breakage, as every existing format and processor demonstrate. PaceTextShouldBeProvided loses the running code argument by an even wider margin than it loses elsewhere. Robert Sayre [0] http://radar.oreilly.com/archives/2005/05/google_web_acce_1.html
Re: PaceNoAlternateForFeed
Tim Bray wrote: On May 9, 2005, at 8:13 AM, Bill de hÓra wrote: Why can't ve just leave a protocol element out if we don't have information for it??? Because it allows someone to assert there is no alternate link for their feed. That's different from leaving an alternate link out. What observable difference in the behavior of software would be affected by this difference? It's not obvious to me that there's a meaningful difference. -Tim The difference is in what can be concluded from the data, ie it's a 3-valued logic problem. Does the absence mean there's no alternate? Does it mean don't unknown? Do we need to care? I think this exercise is *critical* for any piece of markup that is going to move from mandatory to optional. Either way, we should pin down spec language around the optionality of alternate feed links, or consciously decide we're not going to pin it down. cheers Bill
Re: PaceFeedIdOrSelf
On 10/5/05 12:50 AM, Antone Roundy [EMAIL PROTECTED] wrote: I didn't change the Pace, since such a change could conceivably change the opinions of people who've expressed an opinion on it already. But I would be interested to know whether people think this would be an improvement, make it worse, or if either is just as well. +1, an improvement e.
Re: PaceRenameImageToLogo
On 10/5/05 1:14 AM, Antone Roundy [EMAIL PROTECTED] wrote: http://www.intertwingly.net/wiki/pie/PaceRenameImageToLogo +1
Fwd: PaceOptionalSummary
Hi Guys! Did you see this email? Did you notice all the questions about the technical basis of your position? Maybe you should answer them. Also, I'm having trouble reconciling your road lying with the assertion that the two proposals are compatible. How can they be if their outcomes are so different? Robert Sayre On 5/9/05, Bill de hÓra [EMAIL PROTECTED] wrote: I think, more or less, that PaceTextShouldBeProvided only exists because PaceOptionalSummary has not been successfully dismissed. I have no idea why title-only feeds are unfortunate, are an interoperability problem, or an accessibility problem. In fact I felt we had put the accessibility issue to bed weeks ago, but it popped up again in the PaceTextShouldBeProvided's rationale. One thing I would like those who advocate PaceOptionalSummary to the exclusion of all other Paces on the subject to consider... what happens if the chairs determine that consensus can't be found on either of these paces? Look at the current wording of draft-08. Is that what you really want? If the chairs count it up, I think they could find consensus. I think they could have done that a fortnight ago. Or last week. I agree with Robert's paraphrasing, that we are drowning in +1s. And I fail to understand why this has been dragged out so long. There are a few strongly voiced objections, but is that sufficient reason to grind this one out? We can do better. I started out 0 and moved to +1 based on the arguments I saw presented for and against PaceOptionalSummary and my own thinking. I'm -1 on PaceTextShouldBeProvided, and have explained why. I honestly don't know how I can do any better on this. cheers Bill
Re: Last Call: 'The Atom Syndication Format' to Proposed Standard
On 5/9/05, Sam Hartman [EMAIL PROTECTED] wrote: At least based on the discussion the IESG has been copied on, it doesn't sound like the working group has fully considered this issue. The responses have more of the character of those found from people trying to brush aside an issue than of people who have carefully considered something and concluded there is nothing to be done. Moreover, thisn issue cannot be unique to atom: it must effect many XML based protocols both within the IETF and within other standards organizations. Martin, I agree with Sam on both points. Can you give us an example of an XML format that successfully deals with your issue? Does XHTML differ from Atom? Robert Sayre
Re: the atom:copyright element
Antone Roundy wrote: On Sunday, May 8, 2005, at 10:08 AM, Tim Bray wrote: On May 7, 2005, at 3:29 PM, Robin Cover wrote: The publication of a new Implementation Guideline by the Open Archives Initiative (OAI) compels me to suggest once again [1], as Norm Walsh [2], Bob Wyman [3], and others have done before, that the name 'atom:rights' would be better than the (current) element name 'atom:copyright'. +1 +1 from me too. +1 as well. -- Thomas Broyer
Re: PaceOptionalSummary
On Monday, May 9, 2005, at 02:43 PM, Robert Sayre wrote: Did you see this email? Did you notice all the questions about the technical basis of your position? Maybe you should answer them. Also, I'm having trouble reconciling your road lying with the assertion that the two proposals are compatible. How can they be if their outcomes are so different? The change to the spec text proposed by PaceOptionalSummary would also be made by PaceTextShouldBeProvided. In that way, they are compatible. The intents of the authors in writing them was different. In that way, they are incompatible. The intents of people who gave them +1 are not 100% clear. My interpretation is that if someone gave PaceOptionalSummary a +1, but not PaceTextShouldBeProvided, then their intent is close to the author of PaceOptionalSummary. If they gave both a +1, then either they could live with either MAY or SHOULD in the proposed change to section 4.1.2, or their intent is close to the author of PaceTextShouldBeProvided (and they consider the two basically compatible for the reason noted above--ie. looking at the proposed changes to the spec, and not worrying about the authors' intents). I'm in the former group--okay with either MAY or SHOULD. I'd lean more toward SHOULD if we were to come up with a good way to say if there's content, but it's not in atom:content in one of our three special formats, then there SHOULD be a summary--in other words, if one of the following applies: * atom:content/@type is a MIME type rather than text, html or xhtml * there is no atom:content, and some extension element holds the core content of the entry Note that I don't list no atom:content and no extension element holding the content...that's where I lean towards MAY, because to me, the biggest reason for strongly encouraging the use of atom:summary is accessibility. If there's no atom:content or substitute element, then nobody is less able to access the content of the entry than anyone else, because there is no content outside of the metadata elements. The problem with the above is that bullet point #2 isn't checkable without agreement on what constitutes a core-content-holding-extension-element. I don't even want to try to come up with language to describe that--I've participated in this group too long to be that foolish. On 5/9/05, Bill de hÓra [EMAIL PROTECTED] wrote: I think, more or less, that PaceTextShouldBeProvided only exists because PaceOptionalSummary has not been successfully dismissed. I have no idea why title-only feeds are unfortunate, are an interoperability problem, or an accessibility problem. In fact I felt we had put the accessibility issue to bed weeks ago, but it popped up again in the PaceTextShouldBeProvided's rationale. I have no problem with title only feeds. I myself would be far less likely to subscribe to them--or at least they'd have to have extraordinarily well-written, informative titles for me to subscribe to them in just about all cases--but there are certainly valid uses for them.
Re: PaceOptionalSummary
I have no problem with title only feeds. I'm -1 on POS, although I wouldn't describe myself as being positioned in the path of oncoming traffic. Title-only feeds have valid uses, but they're really out of scope for a feed format that only exists because it provides a clearer, cleaner way to deliver content. -- Roger Benningfield
Re: PaceOptionalSummary
On 5/9/05, Antone Roundy [EMAIL PROTECTED] wrote: I have no problem with title only feeds. I myself would be far less likely to subscribe to them--or at least they'd have to have extraordinarily well-written, informative titles for me to subscribe to them in just about all cases--but there are certainly valid uses for them. Do you expect a conformant Atom Processor, such as Jakarta FeedParser, to successfully process title-only feeds? Robert Sayre
Re: PaceOptionalSummary
On 5/9/05, Roger B. [EMAIL PROTECTED] wrote: I have no problem with title only feeds. I'm -1 on POS, although I wouldn't describe myself as being positioned in the path of oncoming traffic. Title-only feeds have valid uses, but they're really out of scope for a feed format that only exists because it provides a clearer, cleaner way to deliver content. Roger, please don't see this as an attack. Here's our charter: -- The format must be able to represent: ... * a feed or channel of entries, with or without enclosed content ... -- I don't think there's a scope argument here. Robert Sayre
Re: Last Call: 'The Atom Syndication Format' to Proposed Standard
At 9:33 AM -0400 5/9/05, Sam Hartman wrote: My personal opinion as someone who is very shortly going to have to evaluate the atom specification is that you've identified an issue (space and line breaking) for some languages that should be considered. Your proposed solution seems highly undesirable in that it requires us to understand the language of the text being displayed. In the past we've had all sorts of problems doing that. Your proposed solution also seems quite complicated. Fully agree. Please note the text in the spec we are working from: If the value is text, the content of the Text construct MUST NOT contain child elements. Such text is intended to be presented to humans in a readable fashion. Thus, Atom Processors MAY collapse white-space (including line-breaks), and display the text using typographic techniques such as justification and proportional fonts. FWIW, this appears twice, identically, in the spec. Martin Dürst brought up CJK (well, actually CJT), saying that they don't use inter-word spacing. That's fine, but it is irrelevant to the text in the draft. If some text comes through with no spaces, there is no white space to collapse. His argument that some XML editors make long lines of text difficult to edit is clearly *way* out of scope for Atom, or any other XML-using protocol for that matter. It may well be that the solutions to this problem are worse than the problem itself. However I think it is important to specifically understand that is the case rather than failing to solve the problem because we failed to understand it. The case is that text that is supposed to be read by humans comes in many forms, with different line lengths, and so on. The paragraph from the spec says that Atom processors may alter these so that they can be presented better for the reader. Of course, they may also alter it to make it less readable, as many mail user agents do (sigh). Regardless, this says that the Atom processor is free to present things in text constructs in any fashion it deems suitable. This is particularly important for making Atom content accessible; for example, the Atom processor can use this rule to present text content by reading it aloud, by putting it on a screen greatly magnified one character at a time, and so on. At least based on the discussion the IESG has been copied on, it doesn't sound like the working group has fully considered this issue. The responses have more of the character of those found from people trying to brush aside an issue than of people who have carefully considered something and concluded there is nothing to be done. Sorry, but that's unfair. Alexy asked Ok, maybe it is just me, but what does it mean to collapse white-space? Does this mean to replace FWS (in RFC 2822 sense) with a single space? Martin's response was orthogonal: Making this more precise is definitely desirable. But there is also an i18n issue: This works fine for languages that use spaces between words. The rest of the thread wandered into the weeds because it was hard to figure out what was being discussed. Moreover, thisn issue cannot be unique to atom: it must effect many XML based protocols both within the IETF and within other standards organizations. Any protocol that has XML that includes human-readable text has this issue. Well, the processors of that XML does; the protocols themselves do not. Anyway as someone evaluating atompub's output it would be very useful if the working group responded to this last call comment. IN my mind a response would start with a researched description of the issue: either confirm that Chinese and Japanese and Thai tools work as described or explain how they actually work. Then describe what other standards have done about this problem. Finally describe what atompub has done about the problem and why. I'm not asking for a lot of text; probably something about as long as this message. I believe that it can be a lot shorter: given the rationale above, it's not a problem for Atompub or any other XML-using protocol. For that matter, it's not really and XML problem at all: it affects text formats like HTML and RFC 2822 as well. --Paul Hoffman, Director --Internet Mail Consortium
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: PaceNoAlternateForFeed
Graham wrote: On 9 May 2005, at 6:48 pm, Bill de hÓra wrote: I think this exercise is *critical* for any piece of markup that is going to move from mandatory to optional. Either way, we should pin down spec language around the optionality of alternate feed links, or consciously decide we're not going to pin it down. So you wouldn't support a proposal that removed a required element without explaining what it's absence meant (eg PaceAtomSummary), because you'd prefer one that leaves it much less ambiguous (eg PaceTextShouldBeProvided, which strongly encourages publishers to only omit atom:summary when none exists)? I'm not surprised at this line of thought since there is also another dicussion going on around optional summaries. You're jumping the gun though and/or possibly trying to pin me into some kind of non-existent corner - fair enough. What I would like is that we at least discuss the consequences of making non-optional things optional on the data beynd some people can't supply meaningful alternates - I happen to be one of those people btw, if I haven't said it already. And some consistency of debate around loosening constraints is good I think. Finally, there is an important distinction between the two cases (optional alternates and optional summaries). The difference is in what can be concluded from the data, ie it's a 3-valued logic problem. Does the absence mean there's no alternate? Does it mean don't unknown? Do we need to care? Answer Tim's question: What observable difference in the behavior of software would be affected by this difference? I can have nullable columns in my database depending on what we decide to do here. That affects the behaviour of my SQL queries and depending. I can can constrain the search for alternates in a nypertext graph if I know the author is saying there is no alternate. That affects (massively in some cases) the behaviour of an RDF query backend among other things. similar arguments can be made for search systems that are working off raw indexes. I can send the message there is no alternate for this feed or no alternate was provided for this feed or no alternate was found for this feed depending on what we decide to do here. Is that enough? Do you see that the point of this pace is to shine some light on what we're doing here? Btw, I'm 0 on PaceNoAlternateForFeed - like I said, I have feeds that have no real alternates. cheers Bill
Re: PaceNoAlternateForFeed
On 5/9/05, Graham [EMAIL PROTECTED] wrote: On 9 May 2005, at 6:48 pm, Bill de hÓra wrote: I think this exercise is *critical* for any piece of markup that is going to move from mandatory to optional. Either way, we should pin down spec language around the optionality of alternate feed links, or consciously decide we're not going to pin it down. So you wouldn't support a proposal that removed a required element without explaining what it's absence meant (eg PaceAtomSummary), No, he consciously decided it wasn't worth pinning down, because there's no interop to be gained. Party foul for bringing this issue up in yet another thread, BTW. because you'd prefer one that leaves it much less ambiguous (eg PaceTextShouldBeProvided, which strongly encourages publishers to only omit atom:summary when none exists)? I've read PaceTextShouldBeProvided, and I don't understand its rationale, but I can tell you there is absolutely nothing in the proposal section which strongly encourages publishers to only omit atom:summary when none exists. All it says is that things might break if you don't include a summary or include empty text constructs. Robert Sayre
Re: PaceFeedIdOrSelf
On Monday, May 9, 2005, at 05:05 PM, Graham wrote: On 4 Apr 2005, at 6:59 pm, Antone Roundy wrote: And add this bullet point: * atom:feed elements that contain no child atom:id element MUST contain an atom:link element with a relation of self. rel=self is in no way a substitute for an identifier Why not? Unless you can explain how multiple different feeds can be obtained via one URI (other than content negotiation to determine the format of the feed or some ridiculous abuse of standards), I disagree completely. @rel=self does precisely identify a feed--the feed pointed to by @href--and while it may be less permanent than atom:id in some cases, it should be sufficiently stable in most cases, and is less spoofable than atom:id, which in my book makes it a better identifier.
Re: PaceFeedIdOrSelf
On Tue, May 10, 2005 at 12:05:22AM +0100, Graham wrote: rel=self is in no way a substitute for an identifier and shouldn't Has anyone considered merging these into one (required) element? The ID can be a URI. The URI need not be resolvable. If the URI is a URL, it SHOULD (MUST?) point to the feed's location. David -- == David Nesting WL7RO Fastolfe [EMAIL PROTECTED] http://fastolfe.net/ == fastolfe.net/me/pgp-key A054 47B1 6D4C E97A D882 C41F 3065 57D9 832F AB01
Re: Which is the preferred feed?
On Mon, May 09, 2005 at 10:53:14AM -0600, Antone Roundy wrote: 302 would result in feed readers (that follow the HTTP spec) continuing to hit the publisher's site every time they checked the feed, and then going to FeedBurner. I'm not sure how user agents would handle it, but one could always attach some caching headers to that 302 response to indicate that the 302 is semi-permanent. In theory, user agents could hold on to that 302 response for a little while and follow the cached redirection. David -- == David Nesting WL7RO Fastolfe [EMAIL PROTECTED] http://fastolfe.net/ == fastolfe.net/me/pgp-key A054 47B1 6D4C E97A D882 C41F 3065 57D9 832F AB01
Re: PaceFeedIdOrSelf
On 10/5/05 11:12 AM, Antone Roundy [EMAIL PROTECTED] wrote: rel=self is in no way a substitute for an identifier Why not? the uri can change. e.
extensions -- Atom NS and unprefixed attributes
I think we should be clearer that new elements in the Atom namespace and unprefixed attributes with parent elements in the Atom namespace can only be added by IETF consensus. Thoughts? Robert Sayre
Re: PaceFeedIdOrSelf
On Tue, May 10, 2005 at 11:52:55AM +1000, Eric Scheid wrote: Why not? the uri can change. URIs don't change; People change them.[1] But yah, things are never that simple. Consequently, ignore my other e-mail in this thread. (And sorry if this is all a re-hash.) David [1] http://www.w3.org/Provider/Style/URI.html -- == David Nesting WL7RO Fastolfe [EMAIL PROTECTED] http://fastolfe.net/ == fastolfe.net/me/pgp-key A054 47B1 6D4C E97A D882 C41F 3065 57D9 832F AB01
Re: PaceFeedIdOrSelf
On 10/5/05 11:36 AM, David Nesting [EMAIL PROTECTED] wrote: rel=self is in no way a substitute for an identifier and shouldn't Has anyone considered merging these into one (required) element? The ID can be a URI. The URI need not be resolvable. If the URI is a URL, it SHOULD (MUST?) point to the feed's location. in the spec the atom:id *is* a URI. introducing SHOULD/MUST point to the feed's location would put pressure on the value of atom:id being changed if the feed is re-located (eg. to FeedBurner). Not a good thing. e.
Re: extensions -- Atom NS and unprefixed attributes
On May 9, 2005, at 6:52 PM, Robert Sayre wrote: I think we should be clearer that new elements in the Atom namespace and unprefixed attributes with parent elements in the Atom namespace can only be added by IETF consensus. Thoughts? I wonder if there's some standard IETF practice when you define a language as regards future change control? Generally -1. This spec defines what Atom 1.0 is, why try to micro-manage the future? -Tim
Atom 1.0?
Question: how do we refer to the product of this WG once it has an RFC number? We definitely need some quick, snappy label to refer to that version to distinguish it from Atom 0.3, which is widely enough deployed that it'll be with us for a while. Per WG consensus, an Atom doc has no version stamp. So there'll be no actual spec-based reason to call our product Atom 1.0. But, we could just go ahead and do it anyhow. Anyone have a better idea? --Tim
Re: extensions -- Atom NS and unprefixed attributes
At 7:22 PM -0700 5/9/05, Tim Bray wrote: On May 9, 2005, at 6:52 PM, Robert Sayre wrote: I think we should be clearer that new elements in the Atom namespace and unprefixed attributes with parent elements in the Atom namespace can only be added by IETF consensus. Thoughts? I wonder if there's some standard IETF practice when you define a language as regards future change control? No. Nearly every protocol tries to go its own way. It's a mess. Generally -1. This spec defines what Atom 1.0 is, why try to micro-manage the future? -Tim Agree on the -1. At 10:34 PM -0400 5/9/05, Robert Sayre wrote: Fair enough. But can just anyone add stuff to the Atom namespace? If the IESG lets them, yes. We gotta trust the IESG after the WG shuts down. Fortunately, they have earned that trust over time. --Paul Hoffman, Director --Internet Mail Consortium
Re: Atom 1.0?
Tim Bray wrote: Question: how do we refer to the product of this WG once it has an RFC number? We definitely need some quick, snappy label to refer to that version to distinguish it from Atom 0.3, which is widely enough deployed that it'll be with us for a while. Per WG consensus, an Atom doc has no version stamp. So there'll be no actual spec-based reason to call our product Atom 1.0. But, we could just go ahead and do it anyhow. Anyone have a better idea? --Tim First time commenting on the list, be gentle. :-) +1 on Tim's suggestion to use Atom 1.0. Atom 0.3 more or less dictates that future version numbers will be referenced in practical usage, so the 1.0 name seems natural. Additionally, it would be unfortunate to be lumped in with RSS in terms of selecting terminology related to versions of the specification (2.0 before 1.0?) These are superficial reasons, but my belief is that this specification will introduce a lot of publishers to the world of syndication. A good name will go a long way to pushing adoption of the specification. Thanks, Jeff Rodenburg
Re: extensions -- Atom NS and unprefixed attributes
On 5/9/05, Paul Hoffman [EMAIL PROTECTED] wrote: Fair enough. But can just anyone add stuff to the Atom namespace? If the IESG lets them, yes. We gotta trust the IESG after the WG shuts down. Fortunately, they have earned that trust over time. I am fine with that. I am concerned that the current draft fails to differentiate between foreign markup and markup that requires IESG approval. Robert Sayre
Re: Atom 1.0?
Tim Bray wrote: Question: how do we refer to the product of this WG once it has an RFC number? We definitely need some quick, snappy label to refer to that version to distinguish it from Atom 0.3, which is widely enough deployed that it'll be with us for a while. Per WG consensus, an Atom doc has no version stamp. So there'll be no actual spec-based reason to call our product Atom 1.0. But, we could just go ahead and do it anyhow. Anyone have a better idea? --Tim non:serious response=joke Let's see: Atom NT, Atom ME, Atom XP, Atom 05... Just kidding. How about AtomRSS X 1.0 Lynx or iAtom? Yeah, yeah, ha ha. Atom++? Atom Ion? an electrically charged particle...fits the tone of the discussion here. Atom Isotope would avoid that connotation. Atom H (H = hydrogen, this first element in the periodic table). Atom Xe might work if it were only for archives (Xe = xenon, an inert gas). Atom Ra might be good for referring back to some of the earlier drafts (Ra = radium...unstable). Atom Cs (Cs = Caesium...we've finally caesed arguing and finalized the spec). Atom Ba (Ba = barium...we can't bear to continue working on the spec...nor to read anymore such jokes? Okay, I'll quit.) /non:serious Seriously though, if we just call it Atom, no one will know whether we're talking about 0.3 or the-format-formerly-known-as-Atom-0.3-before-it-was-finalized, so I think we've got to tack something on to it. It can either be a number, a descriptive name, or a non-descriptive name. A non-descriptive name might require too much explanation, even if it sounded cool. A descriptive name? Might be hard to come up with and/or be too long: Atom: first standardized edition? Atom 1.0 is certainly the easiest way to get the point across. But yeah, it's an odd choice in a way.
Re: Atom 1.0?
On 5/9/05, Antone Roundy [EMAIL PROTECTED] wrote: Tim Bray wrote: Question: how do we refer to the product of this WG once it has an RFC number? We definitely need some quick, snappy label to refer to that version to distinguish it from Atom 0.3, which is widely enough deployed that it'll be with us for a while. Per WG consensus, an Atom doc has no version stamp. So there'll be no actual spec-based reason to call our product Atom 1.0. But, we could just go ahead and do it anyhow. Anyone have a better idea? --Tim I like Atom. non:serious response=joke Foghorn? Liger? Atom 2005 MX Killer Whale? /non:serious
Re: Atom 1.0?
--On May 9, 2005 7:29:58 PM -0700 Tim Bray [EMAIL PROTECTED] wrote: Anyone have a better idea? --Tim Hey, let's vote on a *new* name. I'm +1 on Naked News, because it delivers the news without chrome and crap. Or maybe that is what you get when Atom (Adam?) goes public. Or because sex sells. Seriously, I don't mind Atom 1.0 as long as the next version is Atom 2.0. Please don't increment the right-of-the-dot part forever, because I just had to fix some software that made the (reasonable) assumption that 5.10==5.1, even though 5.10 is really Solaris 10. wunder -- Walter Underwood Principal Architect, Verity
