While I support Shelly's general suggestions that proper process and discussion should be adhered to, I would like to make a point about the notion of a data tag.
However, something like a time stamp really is document metadata. And the concerns that Bruce Lawson brought up about data would be moot if the data tag were well rounded enough to support: <data type="datetime" format="ISO8601" value="..." /> And for non-standard formats you could also provide an event hook: <data type="equation" format="ECMA" value="..." onRender="processEquation()" /> processEquation would process whatever the formatted content is and return HTML so say teh value was: 2^2=4 then the html might be <div>2<sup>2</sup>=4</div> or something supersaturated with CSS. That way the specification nor the user agent developers would have to provide every conceivable standard type/format. Though supporting the core data types (int, float, string, bool, datetime) and at least the W3C formatting options would seem polite. It also means that if systems like twitter or microblogs or macroblogs or whatever want to provide custom data types they can include javascript in their pages that will handle the custom types and the data providers can provide tersly formatted data (like a unix time string) along with its type format and not only might it be a little less data to transfer, but it could be used for sorting by time without transformation and there is full ability to customize output to screen and style it however you want. <data value=""> however, is meaningless and doesn't tell the user agent anything. If that is all that data is then it is seems to go completely counter to the desires of those who drink the semantic web coolaid. And frankly, whether its adopted or not, more sites need to timestamp their content because information has a temporal relevance. In anthropology it is the notion of "ethnographic presence". If you read about some culture that hasn't had much contact with the outside world and read about their traditions and everything and think that it is still true you tend to be surprised when you get there and folks are smoking marlboro's and wearing blue jeans and listening to lady gaga on an ipod. Or more relevant to our industry, we read some article about how much windows sucks only to realize they weren't talking about the latest version they were talking about Windows ME, or the article is talking about how great Windows is but realizing they were talking about Windows XP not Windows 7. While I see value in the data tag, some mechanism for timestamping a document I think is important. Even if you implemented data as described above. The document element should have a datetime attribute or there should be a meta element for indicating that a given date is the date for the current content. And I don't mean an expires by date, but something to indicate what the "present" in the context of a given document. pubdate seems to be somewhat suited for that, but not entirely so, be cause things get re-published. I think file systems nailed this one already with creation date and last modified date. If people aren't using pubdate yet it doesn't mean you should get rid of it. People should use it, and authoring tools should be better about including it. This is where "we only create a specification people will actually use" is a bunch of bs. At some point there is the notion of best practices and advocacy , which are preferable to me as an end user and a developer, rather than submissive compliance. Honestly, pubdate, or lastmodified, or some equivalent content should be a required meta element to aid end-users in determining temporal relevance of a given document. If you tell google and microsoft that google and bing would be able to provide temporally relevant searches if pubdate were properly supported I think they would start supporting it. And once they're on board and proving the content webkit and apple and the rest will follow suit. I have my opinions, but I don't claim to be right. I defer to Shelly's reasoning about document stability and significance of changes without working group consensus. Process may not always be convenient but the specification will be stronger if process is respected. Art C On Oct 30, 2011, at 2:25 PM, Shelley Powers wrote: > I concur with Steve Faulkner's request to revert the change to drop the time > element and replace it with the data element > > http://lists.w3.org/Archives/Public/public-html/2011Oct/0163.html > > In addition to his reasons, I also want to link a writing by Bruce Lawson > with commentary that also express why such a change does not reflect the > interests of the web community at large > > http://www.brucelawson.co.uk/2011/goodbye-html5-time-hello-data/ > > In addition, another concern I have is that this is a major change, with very > little working group discussion or consensus, to a document that is supposed > to be a relatively stable release. Considering that the time element has been > implemented in one browser (Opera) and used in various tools and web sites, I > definitely feel this change generates doubt and confusion about the stability > of the HTML5 specification process. > > This, in addition to the many very valid reasons given for maintaining the > time element, and not introducing another vague, generic element such as div > and span. > > Thank you. > > Shelley Powers >
