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

> Switching back to co-chair mode.... is there a change proposal that captures
> these ideas?  From my read, this seems very similar to:
>
> http://lists.w3.org/Archives/Public/public-html/2010Apr/0193.html
>
> Perhaps the change proposal would benefit from the addition of some
> non-normative descriptions of the (hopefully) relatively uncommon cases
> where this algorithm will produce suboptimal results, as well as guidance
> (namely: add id/bookmark) on how best to avoid those cases?

Done:

Summary
-------

The HTML5 algorithm for turning an HTML page into an Atom feed is
unnecessarily permissive in the generation of entry IDs for the Atom
feed.  It uses a SHOULD condition in the "Otherwise" clause for
determining the entry ID, but should instead use a MUST condition.


Rationale
---------

The Atom spec has a MUST condition in their corresponding text.  This
condition is in fact unenforceable in some cases, but we can get
closer to enforcing it without requiring anything unreasonable for
authors or implementors, and so should require such.


Details
-------

In the section of the HTML5 spec concerning the generation of an Atom
feed from an HTML document (currently section 5.5.3), in the step of
the algorithm detailing how to establish the value of the entry id
(currently step 15.9), change the text following the "Otherwise"
clause to the following:

"
Let id be a user-agent-defined undereferenceable yet globally unique
valid absolute URL. The same absolute URL must be generated for each
run of this algorithm when given the same input. Let has-alternate be
false.

Non-normative note: This may result in a single entry producing
different ids, if the contents of the corresponding <article> change
often.  This may produce an undesirable user experience in Atom feed
consumers, as the single article may exist multiple times in the feed
as distinct entries.  It is recommended that authors ensure that one
of the previous conditions can be met, ensuring a stable id even if
the contents of the article change.
"

As well, I'm not personally clear whether the "this algorithm"
referred to in the first sentence of the "Otherwise" clause is
referring to the overall "produce a feed from a page" algorithm, or
the "produce an entry for the feed from an appropriate <article>"
sub-algorithm.  If the former, the text should be changed to instead
refer to the latter.  This will ensure greater stability of the
generated ids when a feed is produced from, for example, a blog front
page where new articles are regularly added and old articles are
removed.


Impact
------

* The algorithm for generating entry ids uses the appropriate type of
condition, and has a greater chance of creating a good user
experience, since the generated ids are more likely to be stable.

Received on Friday, 16 April 2010 16:41:05 UTC