- From: <bugzilla@jessica.w3.org>
- Date: Sat, 17 Apr 2010 10:12:58 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9546 Summary: computing atom:updated Product: HTML WG Version: unspecified Platform: PC OS/Version: Windows NT Status: NEW Severity: normal Priority: P2 Component: HTML5 spec bugs AssignedTo: dave.null@w3.org ReportedBy: julian.reschke@gmx.de QAContact: public-html-bugzilla@w3.org CC: ian@hixie.ch, mike@w3.org, public-html@w3.org The computation of the atom:updated timestamp for *updated* entries (see <http://greenbytes.de/tech/webdav/rfc4287.html#rfc.section.4.2.15>) surprisingly depends on the presence of <ins>/<del> markup (see <http://dev.w3.org/html5/spec/interactive-elements.html#atom>, Step 15/13). There's nothing really *wrong* about that, but I think the specification needs to clarify that if you don't use <ins>/<del> (with timestamps) on an updated entry, the generated atom:updated will be incorrect. Furthermore, Step 15/15: "If publication date and update date both still have no value, then let them both value a value that is a valid global date and time string representing the global date and time of the moment that this algorithm was invoked." appears to handle the case where no date information is available at all, letting it default to the current date. Again, generating feeds where atom:updated varies with every run of the algorithm seems to be a bad idea to me and supports the argument that producing output for insufficient input data is problematic. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
Received on Saturday, 17 April 2010 10:13:04 UTC