[whatwg] Using BugZilla for non-W3C spec issues

[Ian Hickson]

On Mon, Aug 16, 2010 at 11:58 PM, Julian Reschke <julian.reschke at gmx.de> wrote:
>>> http://www.w3.org/Bugs/Public/show_bug.cgi?id=9546
>>
>> 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.

The note is lower down. It reads: "Note: The above algorithm does not
guarantee that the output will be a conforming Atom feed. In
particular, if insufficient information is provided in the document
(e.g. if the document does not have any <meta name="author"
content="..."> elements), then the output will not be conforming."


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

There is no need to mention this particular case explicitly; there are
all kinds of things that would lead to mistakes, and we already have a
note that says this for the general case.


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

I don't think anyone is disagreeing with that argument. It seems
self-evident that insufficient data in the input will cause problems
with the quality of the output; the industry even has a colloquial
acronym to refer to this concept ("GIGO").


> So filing a new one from within the WHATWG document would have changed
> anything?

No, as noted earlier, the issue was already resolved, and as noted
below, had already received an explicit answer in the context of the
WHATWG.


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

Understood.

Thankfully, since this is a purely editorial issue, it doesn't really
matter either way.


> For the record, this issue is also in WHATWG email (sent on 2010-06-02).

Assuming you are referring to this e-mail:

   http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-June/026574.html

...then it received a reply on August 4th:

   http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-August/027618.html

Please note that resending feedback that has already been handled will
rarely result in a change to the spec, unless new information is
brought to the discussion when the issue is reraised. In this
particular case, no new information was introduced (you just cited the
same bug again).

-- 
Ian Hickson