Re: HTML5 support for <time> element.

On Mar 18, 2012, at 11:55 PM, "Ivan Herman" <ivan@w3.org> wrote:

> Gregg,
> 
> great.
> 
> Caveat: the site seems to be blocked or slow again, I do not get to the test harness... But I looked at the earl report and I pulled the tests from git. Obviously, because some of my tests failed, I looked at the details:-)
> 
> - #278 and #286 is based on the assumption that the value of @content is overridden by the value of @datetime. Did we discuss/decide that? I would definitely think the opposite should be true (and that is the way I have coded it, ie, it is not some sort of a hidden bug). After all @content overrides the enclosed text value, too. If we go along the way you propose, there is no way an RDFa user could put his/her on time value (esoteric it might be) over what is automatically deduced.

Perhaps we didn't discuss it, but thats what's in the spec.

> - The label in the test suite for test #284 seems to be wrong. The test itself is:
> 
>  <time property="rdf:value" datatype="xsd:dateTime"> 2012-03-18Z</time>
> 
> and, I believe, the result should be a plain literal, because the value does not fit the datatype (my implementation actually generates a warning, because I check datatypes for many cases)

The @datatype overrides the format and makes it a typed literal. If the value were "Foo" it would still be a typed literal. In this case, the fact that it's a time element is irrelevant.

Gregg

> I have two more cases (280 and 287) where my implementation does not pass; I have to investigate those further.
> 
> Ivan
> 
> 
> On Mar 19, 2012, at 01:30 , Gregg Kellogg wrote:
> 
>> I added tests 0272 through 0288 to test various HTML5 processor requirements, based on my understanding of the current spec and WG decisions. I've re-run EARL tests and the results can be seen in [1].
>> 
>> It would be worth checking the tests I added to see if they are reasonable. Areas that are not entirely clear:
>> 
>> * support for xsd:duration, xsd:gYear and xsd:gYearMonth in addition to xsd:date, xsd:time and xsd:dateTime.
>> * use of <time> element textual value when it is an exact lexical match to one of these datatypes.
>> * use of @data as a resource attribute similar to @href and @src. (the spec just mentions this in a note, and doesn't define a precedence, I presume it has a higher precidence then @href or @src).
>> 
>> Also, note that I pub HTML5, SVG and XHTML into a separate section for "Other Host Languages", as they're either not specified, or are not at a CR level as Ivan suggested.
>> 
>> Note that the ReSpec file is getting large enough that processing time is a consideration, we may want to reference a compiled version.
>> 
>> Gregg
>> 
>> [1] http://rdfa.info/earl-reports/
>> 
>> On Mar 18, 2012, at 1:11 PM, Gregg Kellogg wrote:
>> 
>>> On 2011-11-17, we decided to support the HTML5 time element, with xsd:date, xsd:time, and xsd:dateTIme support and the intention to follow the time element for subsequent datatypes. I think the expectation was that there would be an updated W3C working draft that shows this, but the HTML5 group has not released an updated WD in about 10 months (aparently, the WHATWG process is sufficient for their needs).
>>> 
>>> For the Microdata to RDF spec we decided to go ahead and add support for xsd:duration, xsd:gYear, and xsd:gYearMonth. As I think it's clear that this will ultimately be expressed in a W3C draft, I'm going to create tests that verify this for HTML5 and XHTML5. IMO, the spec should be updated as well, which I'd be happy to do, but I don't seem to have access to the CVS repo.
>>> 
>>> Gregg
>>> 
>>> 
>> 
>> 
> 
> 
> ----
> Ivan Herman, W3C Semantic Web Activity Lead
> Home: http://www.w3.org/People/Ivan/
> mobile: +31-641044153
> FOAF: http://www.ivan-herman.net/foaf.rdf
> 
> 
> 
> 
>

Received on Monday, 19 March 2012 07:03:00 UTC