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

Thank you for your submission!

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

Regards,
Maciej


On Apr 6, 2010, at 2:12 PM, Julian Reschke wrote:

> Hi,
>
> below is a change proposal for this issue.
>
> Note that an obvious alternative to fixing the algorithm would be to  
> remove the section completely.
>
> Best regards,
>
> Julian
>
> -- snip --
> SUMMARY
>
> The HTML5 spec contains an algorithm for producing an Atom (RFC4287)  
> feed document from an HTML page.
>
> The definition both relaxes a MUST-level requirement from RFC4287,  
> but also adds a needless restriction.
>
> 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).
>
> RATIONALE
>
> Instructions to derive a secondary format from HTML documents  
> shouldn't be misleading, and also should make clear which conditions  
> need to be met to produce valid documents.
>
> DETAILS
>
> There are two problems, both with the following step (4.15.1, step  
> 15.9 as of April 6):
>
> "Otherwise
>
>    Let id be a user-agent-defined undereferenceable yet globally  
> unique valid absolute URL. The same absolute URL should be generated  
> for each run of this algorithm when given the same input. Let has- 
> alternate be false."
>
> Problem #1: RFC 4287 does not require the ID to be  
> undereferenceable. This was a conscious decision of the IETF AtomPub  
> WG. There's absolutely no point in adding this requirement, except  
> for the spec author's distaste for URIs that are both  
> dereferenceable *and* act as a globally unique and stable identifier.
>
> Note from <http://greenbytes.de/tech/webdav/rfc4287.html#rfc.section.4.2.6.p.2 
> >:
>
> "...Though the IRI might use a dereferencable scheme, Atom  
> Processors MUST NOT assume it can be dereferenced."
>
> Problem #2: RFC 4287 makes it a MUST-level requirement to generate  
> the same ID every time the feed is regenerated:
>
> From <http://greenbytes.de/tech/webdav/rfc4287.html#rfc.section.4.2.6.p.3 
> >:
>
> "When an Atom Document is relocated, migrated, syndicated,  
> republished, exported, or imported, the content of its atom:id  
> element MUST NOT change. Put another way, an atom:id element  
> pertains to all instantiations of a particular Atom entry or feed;  
> revisions retain the same content in their atom:id elements. It is  
> suggested that the atom:id element be stored along with the  
> associated resource."
>
> HTML5 relaxes this to a should-level requirement.
>
> I do agree that generating valid Atom feeds from HTML *is* hard, but  
> violating a MUST-level requirement from the Atom spec is not  
> acceptable.
>
> Proposed changes:
>
> For issue #1:
>
> Leave out "undereferencable", changing the sentence to:
>
> "Let id be a user-agent-defined yet globally unique valid absolute  
> URL."
>
> For issue #2:
>
> Change
>
> "The same absolute URL should be generated for each run of this  
> algorithm when given the same input."
>
> to
>
> "The same absolute URL must be generated for each run of this  
> algorithm when given the same input. If this requirement can not be  
> fulfilled, then generating a valid Atom feed is not possible and  
> this algorithm should be aborted."
>
>
> IMPACT
>
> 1. Positive Effects
>
> Consistency between the applicable specs. Also, authors are  
> correctly informed about what it takes to generate proper Atom feeds.
>
> 2. Negative Effects
>
> None.
>
> 3. Conformance Classes Changes
>
> Atom feed generators are actually required to generate valid Atom  
> documents (with respect to atom:id).
>
> 4. Risks
>
> None.
>
> REFERENCES
>
> Inline.
>
>
>
>

Received on Wednesday, 7 April 2010 00:46:46 UTC