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

Re: change proposal for issue-86, was: ISSUE-86 - atom-id-stability - Chairs Solicit Proposals

From: Julian Reschke <julian.reschke@gmx.de>
Date: Fri, 09 Apr 2010 16:04:55 +0200
Message-ID: <4BBF3407.2050700@gmx.de>
To: Maciej Stachowiak <mjs@apple.com>
CC: "public-html@w3.org WG" <public-html@w3.org>
On 08.04.2010 20:12, Maciej Stachowiak wrote:
> On Apr 8, 2010, at 5:09 AM, Julian Reschke wrote:
>> Also, it's not clear *at all* whether this is a feature that people
>> really want, and if they do, whether it needs to be part of HTML5.
>> Given the fact that it's non-trivial to generate a valid Atom feed
>> from HTML, but the reverse *is* trivial, we should also consider
>> removing this feature altogether (I'd be happy to write a 2nd change
>> proposal if people want to see that as well). (See [2])
> Since a number of people have expressed interest, I think it would be
> helpful to provide a second proposal along these lines.

Sure. Here it is:


The HTML5 spec contains an algorithm for producing an Atom (RFC4287) 
feed document from an HTML page.

There are many problems with this, summarized under RATIONALE.

This Change Proposal removes the complete section defining this algorithm.


The are multiple problems with the algorithm for Atom generation:

1) It's not clear that a sufficient amount of people is interested in 
this. HTML pages that would be candidates for this usually are generated 
from a different source, like an article database, or even a feed 
document. Therefore, providing both simply is not a problem for the 
author. Defining a feature that is of little use increases the spec size 
(more to review) and the risk of getting things wrong because of poor 
review (see below).

2) Defining a mapping between both formats *is* interesting. Other 
parties have done it before. This is even mentioned in HTML5. There's no 
reason why another variant of this needs to be in HTML5.

3) The mapping as currently specified contradicts the Atom specification 
(RFC 4287) in several aspects. If this Change Proposal does not get 
applied, the individual problems with the mapping still will need to be 
fixed. There's a separate Change Proposal ([1]) which is focused on 
fixing some of these issues.


Remove all of 4.15.1 ("Atom"). Also remove 4.15 ("Converting HTML to 
other formats"), which otherwise would be empty.

Note: the removal of this part should be applied to all variants of the 
spec, be it in W3C space or not. Otherwise, the algorithm will need 
proper review, and I'd recommend to encourage the members of the 
atom-syntax mailing list to do that.


1. Positive Effects

Removal of spec text which is believed to be non-essential, 
controversial, in contradiction with other applicable specs, and 
potentially buggy.

2. Negative Effects


3. Conformance Classes Changes

None (there was non requirement to implement this anyway).

4. Risks



[1] <http://lists.w3.org/Archives/Public/public-html/2010Apr/0291.html>
Received on Friday, 9 April 2010 14:05:36 UTC

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