[microformats-discuss] FYI: Boyd on Microformats and
Tantek Ç elik
tantek at cs.stanford.edu
Mon Oct 10 17:44:28 PDT 2005
On 10/10/05 5:33 PM, "Craig Ogg" <craig.ogg at gmail.com> wrote:
> On 10/10/05, Tantek Çelik <tantek at cs.stanford.edu> wrote:
>> On 10/10/05 4:26 PM, "Craig Ogg" <craig.ogg at gmail.com> wrote:
>>> In that same article, Stowe Boyd says, "Turns out I just had a
>>> conceptual problem: I was thinking that dtend worked differently. If
>>> an event is intended to run on 15 Nov, without a tipulated hour of
>>> ending, then you should encode dtend as 16 Nov!)"
>>> If he is correct, this seems to me to be a violation of the "human
>>> first, computers second" principle.
>> I'm not sure I understand how you came to that conclusion. Could you
>> explain a little?
>> This message is short and to the point:
> I recognize the date convention from SQL -- essentially there is an
> invisible time component of 00:00:00. This is probably one of the
> most common sources of bugs in SQL queries -- it just doesn't make
> sense to most people. More importantly, to readers of the page the
> tooltip actually seems to disagree with what author wrote. "Which is
> it???" Even as a programmer, this was my immediate reaction.
Yep, I must admit that I too have a similar reaction.
> I understand this is being done to not reinvent the wheel, I just
> thought I would point out that it is problematic and will likely
> result in a lot of incorrect markup.
Maybe. I'm wondering how much that is actually going to be the case. The
nice thing is, now that *we* understand this, we can do our best to make
sure the tools etc. take care of this as much as possible. Perhaps for this
case, we can even insert an markup comment in the code, so that any
programmer doing a view source can see that and realize "Oh, I see...".
I'd rather wait to see the problems actually happen and then adapt, rather
than pre-planning for them to happen. I think with the rapid feedback-loop
of the web, this may be less of a problem than we might think.
> Part of the problem is people
> see "dt" and pronounce it "date" rather than "datetime" which is what
> it probably stands for.
> Perhaps creating new classes "datestart" and
> "dateend" (no time component allowed) and stating that dtstart and
> dtend should state the time component would remove the ambiguity. I
> don't think that solution is ideal either though.
Yes, I think it is even worse to add new classes and extend iCalendar
RFC2445 at this point.
Let's see if we can make this work first.
My instinct says that being consistent with RFC2445 (as much as we can) is
likely to yield fewer overall bugs than if we were to deviate a little.
More information about the microformats-discuss