Re: HTML5 support for <time> element.

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

Received on Monday, 19 March 2012 00:31:45 UTC