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

I support the proposal to remove the HTML transformations as well.

Besides the technical issues on linking it to the Atom standard, which
itself might change, or lose favor of developers over time, there is the
practical problem of statistics. Hosting just under a million forums and
blogs with RSS feeds, I can tell you that it is of great consequence that
the page url and the feed url are separate. It is one thing to filter out a
few big crawlers for page views, but to also have to filter out feed readers
(of which there are many) for statistics would be a nightmare. Just missing
a few would give someone the impression that their blog is popular, when
really only one person reads it but has a reader redownloading the page all
the time. Then there is advertising differences, etc., as well. And if the
CMS tries to navigate those differences, you have to worry how Google et al
punish sites that display different content to different clients.

I can see large sites looking at the spec and seeing that section as a
warning of what might happen if the spec is adhered to closely. And I can
see feed reader developers seeing this as a cool new (preferred?) way of
consuming content. The two sides will read the same thing and come to
opposite conclusions.

If the Atom part of the HTML5 spec is to stay then it should include at
least a few things like: you must use a special HTTP header x-feed-reader:
true when getting a page, and don't do the transform if there is a link to a
feed in the header.

Steven Roussey


On Fri, Apr 9, 2010 at 11:19 AM, Shelley Powers <shelley.just@gmail.com>wrote:

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