W3C home > Mailing lists > Public > public-html@w3.org > April 2010

Re: ISSUE 86 and removing atom transform section - focusing

From: Sam Ruby <rubys@intertwingly.net>
Date: Fri, 16 Apr 2010 20:33:27 -0400
Message-ID: <4BC901D7.3050201@intertwingly.net>
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 

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

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:16:01 UTC