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

On Apr 16, 2010, at 9:40 AM, Tab Atkins Jr. wrote:

>> Switching back to co-chair mode.... is there a change proposal that  
>> captures
>> these ideas?  From my read, this seems very similar to:
>> 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 Tuesday, 20 April 2010 11:05:48 UTC