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

On 04/09/2010 10:04 AM, Julian Reschke 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:

Given that discussion has died down, and that this proposal has gotten 
several indications of support and (as of yet) no objections, at this 
time I would like anybody in the Working Group that has reason to object 
to this item to state so now.  If none come forward, the chairs will 
issue a Call for Consensus.

- Sam Ruby

> 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>
>
>

Received on Wednesday, 14 April 2010 15:05:30 UTC