- 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