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

On Fri, Apr 9, 2010 at 9:04 AM, Julian Reschke <julian.reschke@gmx.de> wrote:
> 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:
>
> SUMMARY
>
> 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.
>
> RATIONALE
>
> 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.
>
>
> DETAILS
>
> 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.
>
>
> IMPACT
>
> 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
>
> None.
>
> 3. Conformance Classes Changes
>
> None (there was non requirement to implement this anyway).
>
> 4. Risks
>
> None.
>
> REFERENCES
>
> [1] <http://lists.w3.org/Archives/Public/public-html/2010Apr/0291.html>
>
>
>

I support this proposal.

Shelley

Received on Friday, 9 April 2010 18:20:19 UTC