Re: Clarify datetime rule in 3.1 Additional RDFa Processing Rules

Also, we have to determine whether the @datetime attribute actually
has been renamed to @dateTime? Where is the reference to this
decision, and is there any draft of HTML5 incorporating it? As it was
explained, the reason for the renaming was said to be because that's
what it's named in HTML4 and XHTML 1.1 (used on the ins and del
elements). But that does not seem to be true [1], [2].

I find this change to HTML5 quite disconcerting. (Might there have
been a miscommunication? Perhaps the renaming was in the DOM API? If
it's called `dateTime` in the DOM, that's an entirely different
matter, which does not concern this spec.)

Cheers,
Niklas

[1]: http://www.w3.org/TR/html4/struct/text.html#adef-datetime
[2]: http://www.w3.org/TR/xhtml-modularization/abstract_modules.html#s_editmodule


On Sun, Mar 10, 2013 at 10:17 PM, Niklas Lindström <lindstream@gmail.com> wrote:
> Hi all,
>
> I think we should formulate the @datetime rule in "3.1 Additional RDFa
> Processing Rules" a little better. It currently reads:
>
> [[[
> * In Section 7.5: Sequence, processing step 11, the HTML5 @datetime
> attribute must be utilized when generating output. If @datetime is
> detected and the value of the attribute is a valid xsd:date, xsd:time,
> xsd:dateTime, xsd:duration, xsd:gYear, or xsd:gYearMonth, then a
> triple must be generated where the current property value is the
> matching xsd datatype and the value is the value contained in the
> @datetime attribute. If @datatype is specified, it must take
> precedence. If no @datatype is specified, and the value does not match
> any of the automatically detected xsd datatypes, a plain literal must
> be generated with the associated language of the node, if available.
> If @content is specified on the same element, it must take precedence
> over @datetime and the contents of the element and must be processed
> according to the rules defined in [RDFA-CORE].
> ]]]
>
> I find the text somewhat tricky to follow. Also, the part: "then a
> triple must be generated where the current property value is the
> matching xsd datatype and the value is the value contained in the
> @datetime attribute" seems a bit strange. For one, the "current
> property value" is *of* the matching xsd datatype.
>
> I suggest to change the text block to:
>
> [[[
> * In Section 7.5: Sequence, processing step 11, the HTML5 @datetime
> attribute must be utilized when generating the current property value,
> unless @content is also present on the same element. Otherwise, if
> @datetime is present, the current property value must be generated as
> follows. The literal value is the value contained in the @datetime
> attribute. If @datatype is present, it is to be used as per usual.
> Otherwise, if the value of @datetime lexically matches a valid
> xsd:date, xsd:time, xsd:dateTime, xsd:duration, xsd:gYear, or
> xsd:gYearMonth, a typed literal must be generated, with its datatype
> being the matching xsd datatype. Otherwise, a plain literal must be
> generated, taking into account any current language available.
> ]]]
>
> Thoughts?
>
> Cheers,
> Niklas

Received on Sunday, 10 March 2013 21:22:03 UTC