- From: Sam Ruby <rubys@intertwingly.net>
- Date: Fri, 16 Apr 2010 20:33:27 -0400
- To: Shelley Powers <shelley.just@gmail.com>
- CC: sroussey@network54.com, Maciej Stachowiak <mjs@apple.com>, "Tab Atkins Jr." <jackalmage@gmail.com>, HTMLWG WG <public-html@w3.org>
On 04/16/2010 07:09 PM, Shelley Powers wrote: > On Fri, Apr 16, 2010 at 5:37 PM, Steven Roussey<sroussey@gmail.com> wrote: >> I still assert that using the html as a feed is a bad idea, regardless of >> any algorithm change: >> >> http://lists.w3.org/Archives/Public/public-html/2010Apr/0506.html >> >> Steven Roussey >> >> On Fri, Apr 16, 2010 at 2:50 PM, Maciej Stachowiak<mjs@apple.com> wrote: >>> >>> On Apr 16, 2010, at 2:34 PM, Tab Atkins Jr. wrote: >>> >>>> I object to summarily removing it. If it does become an LC blocker, >>>> I'd support removing it; it'll remain the WHATWG version of the spec >>>> in any case. I believe the issues with the algorithm are minor and >>>> can be resolved quickly, though. >>> >>> All right, let's see if we can come up with an algorithm change that no >>> one objects to, otherwise this issue may end up going to a poll and written >>> decision. >>> >>> Regards, >>> Maciej > > I also object to keeping the section, and to continuing the discussion > on the algorithm until this higher level decision is made. If this > becomes a WhatWG thing, then it can be resolved in the WhatWG email > list. Or perhaps among the Atom community, who can provide assistance. > > Shelley Because I will take a position on this issue, I'll leave how it should be handled to Maciej and Paul. My take is that what is currently in the spec is something I would strongly object to, for reasons that I and others have already stated. I do see aspects in Tab's change proposal that I would call plausible, and aspects where there are unnecessary restrictions which are in place to solve what I frankly believe to be non-problems (e.g., insistence that the URI be non-dereferenceable, I believe that most will end up doing this anyway, so network effects would discourage the creation of clients that relied on anything else). That being said, "plausible" is not enough to convert my position, nor do I believe that the issues are know yet, nor can the ones that are konwn be resolved quickly. To the contrary, I believe that this is an area that would benefit from more implementation experience prior to standardization. I will keep an open mind, and as such, I have no problem with people continuing to work on an algorithm, and if they do, either here or elsewhere, and if they do, I will provide input. I do encourage continuing to include that atompub mailing list. Now, to Tab: by definition issue 86 is a Last Call blocker. As such, I believe that you have already said that you would support removing this algorithm, and presumably would be even more OK with doing so under the conditions that Maciej originally stated[1] where this function could could come back either as a separate spec or into the main draft -- if and when the technical issues are worked out to everyone's satisfaction. As such, my suggestion is that you consider lifting your objection now; there truly is no "summarily" about the removal, nor has anybody suggested any irreversible actions at this point. All we are saying is that this algorithm is not fully baked just yet, and could benefit from some implementation experience prior to standardization. - Sam Ruby [1] http://lists.w3.org/Archives/Public/public-html/2010Apr/0514.html
Received on Saturday, 17 April 2010 00:34:02 UTC