W3C home > Mailing lists > Public > public-html@w3.org > April 2010

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

From: Maciej Stachowiak <mjs@apple.com>
Date: Tue, 20 Apr 2010 04:05:12 -0700
Cc: Sam Ruby <rubys@intertwingly.net>, Ian Hickson <ian@hixie.ch>, Edward O'Connor <hober0@gmail.com>, Julian Reschke <julian.reschke@gmx.de>, "public-html@w3.org WG" <public-html@w3.org>
Message-id: <788C0B8F-3C5B-4E27-9499-FF759D423220@apple.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>

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

Recorded:
http://dev.w3.org/html5/status/issue-status.html#ISSUE-086

Thanks,
Maciej

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

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:17 UTC