W3C home > Mailing lists > Public > public-rdfa-wg@w3.org > March 2013

Re: Clarify datetime rule in 3.1 Additional RDFa Processing Rules

From: Ivan Herman <ivan@w3.org>
Date: Mon, 11 Mar 2013 09:25:21 +0100
Cc: public-rdfa-wg <public-rdfa-wg@w3.org>
Message-Id: <4FCDFDAA-CEBA-49A5-BE9B-5888B2825489@w3.org>
To: Niklas Lindström <lindstream@gmail.com>
Indeed, it is a bit messy.

I am more in more in favour of the OWL 2 strategy, I must admit (although this is still to be discussed).

For those who do not know. OWL 2, when first published, had a dependency on XSD 1.1. This dependency was actually very serious: the whole datatype handling depended on how datatypes are defined, and XSD 1.1 introduced some major changes. XSD 1.1 was in CR when OWL 2 was published. So what happened is as follows:

1. OWL 2 was published in 2009 with the following remark in the status section:

[[[
XML Schema Datatypes Dependency

OWL 2 is defined to use datatypes defined in the XML Schema Definition Language (XSD). As of this writing, the latest W3C Recommendation for XSD is version 1.0, with version 1.1 progressing toward Recommendation. OWL 2 has been designed to take advantage of the new datatypes and clearer explanations available in XSD 1.1, but for now those advantages are being partially put on hold. Specifically, until XSD 1.1 becomes a W3C Recommendation, the elements of OWL 2 which are based on it should be considered optional, as detailed in Conformance, section 2.3. Upon the publication of XSD 1.1 as a W3C Recommendation, those elements cease to be optional and are to be considered required as otherwise specified.

We suggest that for now developers and users follow the XSD 1.1 Candidate Recommendation. Based on discussions between the Schema and OWL Working Groups, we do not expect any implementation changes will be necessary as XSD 1.1 advances to Recommendation.
]]]


2. When was finally published as a Rec, OWL 2 was re-published in 2012 as an _edited_ rec (labeled '2nd edition') with the following change added in the appendix:

[[[
	• With the publication of the XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes Recommendation of 5 April 2012, the elements of OWL 2 which are based on XSD 1.1 are now considered required, and the note detailing the optional dependency on the XSD 1.1 Candidate Recommendation of 30 April, 2009 has been removed from the "Status of this Document" section.
]]]

In the meantime, the OWL WG was 'dormant', ie, no meeting, nothing; it was woken up to issue a PER request, get it through an AC vote, and publish the doc. In the case of OWL 2 it was a bit of a pain, because this meant publishing around 7-8 rec documents, which were all edited on the Wiki and needed some Sandro magic to produce a Rec. In our case we are having only one document altogether, using respec. So it may be easier.

This could take care of both our HTML5 and RDF 1.1 dependencies. In the meantime, HTML5+RDFa is a Rec, and we make it very clear that the only change we are envisaging is the one above. No other change would be considered; ie, the document can be considered as stable. It did not create any problems for the deployment of OWL 2, for example.

Just food for thoughts...

Ivan




On Mar 10, 2013, at 22:21 , Niklas Lindström <lindstream@gmail.com> wrote:

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


----
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, 11 March 2013 08:25:39 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:19:58 UTC