- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Tue, 17 Aug 2010 08:58:20 +0200
- To: Ian Hickson <ian@hixie.ch>
- CC: WHATWG <whatwg@whatwg.org>, "public-html@w3.org" <public-html@w3.org>
On 17.08.2010 08:46, Ian Hickson wrote: > > Please don't cross-post e-mails to the WHATWG list. It causes thread > fragmentation. The issue affects both groups. > On Tue, 17 Aug 2010, Julian Reschke wrote: >> >> <http://www.w3.org/Bugs/Public/show_bug.cgi?id=9546> is about a bug in the >> HTML-to-Atom algorithm, which only survived in the WHATWG document. > > As far as I can tell, the bug is already resolved. There's already a note > pointing out what you are requesting a note to point out. I don't see any note on the requirements on the source for computing a usable atom:updated element. Citing the original bug report: "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." >> Ian has rejected the bug as "Invalid use of the bug tracking system". >> >> Of course the bug is still there, and the WHATWG document actually points to >> the W3C BugZilla instance for feedback. >> >> Something is wrong here. > > That particular bug was not filed using the bug filing tool in the spec, > so I assumed it was a W3C HTML WG bug only. See <http://www.w3.org/Bugs/Public/show_bug.cgi?id=9546#c4>. So filing a new one from within the WHATWG document would have changed anything? Sounds very bureaucratic to me. > In general, the way to report problems with the WHATWG specs is to send an > e-mail to this mailing list. The bug system is a convenience, but since > it's using another working group's bug reporting system, it shouldn't > really be considered to be part of the WHATWG processes. That's why I asked not to use it in this case. > If there is still a problem with the WHATWG spec's Atom conversion > section, please send an e-mail to this mailing list. I can't tell from the > bug cited above what problem you are concerned about; it seems fixed > already. I disagree that it is fixed. >> Please either accept bugs for non-W3C portions, or change the feedback >> system on the WHATWG document. > > I've updated the system to not send bugs filed on the Atom section to the > "HTML5" component at the W3C, since that section isn't in HTML5. However, > that wouldn't affect the particular bug cited above, since it didn't use > that system. (For the record, the bug reporting system's use of the W3C > bug database is done in coordination with W3C staff.) Thanks for making that change. For the record, this issue is also in WHATWG email (sent on 2010-06-02). Best regards, Julian
Received on Tuesday, 17 August 2010 06:59:13 UTC