W3C home > Mailing lists > Public > public-html@w3.org > November 2011

Re: noted 3 issues re: time/data (was Re: minutes for HTML WG f2f, 2011-11-04, part 1)

From: Marat Tanalin | tanalin.com <mtanalin@yandex.ru>
Date: Fri, 11 Nov 2011 01:39:39 +0400
To: Tantek Çelik <tantek@cs.stanford.edu>
Cc: Sam Ruby <rubys@intertwingly.net>,public-html@w3.org
Message-Id: <174931320961180@web143.yandex.ru>
> 2. Introduction of the data element. There are enough use-cases of the
> general class of human vs. machine data publishing that justify a
> simple data element for use with microformats, microdata, RDFa.
> http://www.w3.org/wiki/User:Tantekelik/data_element

I think <data> element is completely unneeded since attribute named like 'itempropvalue' could be used for exactly same purposes (see bug 14679, [1]). The attribute could be used with _any_ structural elements (like DD or EM) _already_ used in a specific text, thus not leading to littered tag-soup.

> 3. Drop pubdate attribute. The pubdate attribute is a vestigial piece
> of markup left-over from the attempt to provide automatic HTML5 to
> Atom conversion, and in practice is either not used, or typically used
> in conjunction with the hAtom microformat which doesn't supersets its
> functionality.

Most of real-world authors don't care about Atom. They just want to _add semantic sense_ to their HTML content. 'pubdate' attribute is part of this semantics and therefore should _not_ be dropped. Additionally, supplementary 'update' (or 'pubupdate') boolean attribute should be added to markup _update_ dates (see bug 14202, [2]).

At the same time, dropping DOM attribute 'valueAsDate' is OK for me since such dropping would remove redundant and unneeded complexity from <time> part of spec.

Any automated localization transformations of TIME elements content or value are probably unneeded too. Authors need just a way to markup dates and times, be it publication date or years in historical texts or any other elementary dates. TIME element should be as easy to use as EM or BLOCKQUOTE are.

Thanks.

Bugs mentioned above:
[1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=14679
[2] http://www.w3.org/Bugs/Public/show_bug.cgi?id=14202


10.11.2011, 21:07, "Tantek Çelik" <tantek@cs.stanford.edu>:
> On Sat, Nov 5, 2011 at 19:01, Sam Ruby <rubys@intertwingly.net> wrote:
>
>>  On 11/05/11 8:58 PM, Tantek Çelik wrote:
>>>>  From the minutes:
>>>>  PC: there is further dialog
>>>>   ... there is a call for change proposals closing today, Nov 4.
>>>  I just saw this and likely need another day or two.
>>  The minutes have two lines out of order.  That comment was meant to apply to
>>  issue 180, which had a call for proposals which closed yesterday:
>>
>>  http://lists.w3.org/Archives/Public/public-html/2011Oct/0028.html
>
> Thanks for the clarification Sam. Appreciated.
>
>>>  I've been drafting
>>>  a change proposal this past week to add back the enhanced time (as
>>>  shown this past Thursday at 11:30) and have continued to update it
>>>  with details (the core functionality is unchanged from what was
>>>  proposed, since the specific feature set had consensus without
>>>  objections from those that advocated keeping<time>)
>>>
>>>  Here is the URL to the living change proposal to re-add an enhanced
>>>  time element:
>>>
>>>  http://www.w3.org/wiki/User:Tantekelik/time_element
>>  Given that there has been a revert request, the next step will be to
>>  identify one or more issues.  Based on the sense of the room, and the
>>  direction you are taking, it may make sense to split apart the discussion of
>>  keep/remove/improve the time element and the discussion about adding a data
>>  element.
>>
>>  The right next step here is to identify one or more issue are.  Once that is
>>  done, there will be a minimum of 30 days given to allow proposals to be
>>  created.
>
> And thanks for helping explain the next steps. I see three issues
> which are semi-related but can be semi-independently addressed.
>
> 1. Reintroduction of the enhanced time element. Use-cases/needs have
> been demonstrated for an enhanced time element and thus we should add
> it.
> http://www.w3.org/wiki/User:Tantekelik/time_element
>
> 2. Introduction of the data element. There are enough use-cases of the
> general class of human vs. machine data publishing that justify a
> simple data element for use with microformats, microdata, RDFa.
> http://www.w3.org/wiki/User:Tantekelik/data_element
>
> 3. Drop pubdate attribute. The pubdate attribute is a vestigial piece
> of markup left-over from the attempt to provide automatic HTML5 to
> Atom conversion, and in practice is either not used, or typically used
> in conjunction with the hAtom microformat which doesn't supersets its
> functionality.
>
> Sam, your guidance as to how best document/progress these three issues
> is appreciated.
>
>>>  I'd like to also see the<data>  element introduced - there are
>>>  numerous additional uses in microformats for a generic<data>  element
>>>  and we can use it over time to gather data on what other (if any)
>>>  specific elements we could use in the future (rather than
>>>  hypothesizing too many up front). There was also rough consensus in
>>>  the HTML WG f2f *for* adding a data element.
>>  There was rough consensus of the participants in the f2f, but by policy we
>>  allow asynchronous participation via mailing list.
>
> And I very much appreciate that policy myself. My note was simply to
> confirm/note on-record of the rough f2f consensus.
>
>>>  Here is the URL to the living change proposal to add a data element:
>>>
>>>  http://www.w3.org/wiki/User:Tantekelik/data_element
>>>
>>>  I'll probably need another day or so to have reasonable draft change
>>>  proposals though each has a reasonable outline at this point.
>>>
>>>  Comments and suggestions for improvements welcome for both change
>>>  proposals.
>>  I will note that there is one concern that has been identified with the
>>  definition of the data element as currently specified:
>>
>>  http://www.w3.org/Bugs/Public/show_bug.cgi?id=13240#c72
>>
>>  See the last paragraph in that comment.  Given the sentiment in the room in
>>  the F2F, if that concern can be addressed and no other concerns are voiced,
>>  it occurs to me that we could move this forward quickly with a Call for
>>  Consensus.  Should anybody object, we would give those who do an opportunity
>>  to produce counter proposals.
>
> I agree with the noted issue in the last paragraph in that comment. I
> think it makes sense to provide examples that are either theoretical
> with example.com, or make use of well-established/adopted open
> community resources (or both). Additional a variety of syntax examples
> (microformats, microdata, RDFa, microformats-2) would also be
> reasonable.
>
> Thanks,
>
> Tantek
>
> --
> http://tantek.com/ - I made an HTML5 tutorial! http://tantek.com/html5
Received on Thursday, 10 November 2011 21:41:52 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:28 UTC