This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Consider this markup: <body prefix="dc: http://purl.org/dc/terms/"> <time datetime="2010-10-29T15:48:11" property="dc:modified" pubdate>October 29th 2010 at 11:48 AM</time> <time datetime="2010-10-29T15:36:24" property="dc:created">October 29th 2010 at 11:36 AM</time> </body> I would like the @content attribute to be inferred from the time's @datetime. In the spec right now it seems that the @content attribute will get the text contents of the time tag, in this case "October 29th 2010 at 11:48 AM". Which is invalid. Or perhaps the markup is invalid, because the @content is missing. But it SHOULD be an error to say something like <time datetime="2010-10-29T15:48:11" property="dc:modified" content="2007-01-01"> That's valid markup -- it's possible to set @content to any valid W3 date value -- but what are the semantics? (I have not participated in semantic web activity in about 7 years, and my specification-reading skills have blown away. So perhaps the current draft HTML+RDFa spec already has this. But I don't think so.)
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Technical issues with proposal Technical Description: The submitter has asked that the processing rules for HTML5+RDFa be changed such that @datetime is considered when executing Step #11 of the Processing Sequence in RDFa Core 1.1: http://www.w3.org/TR/rdfa-core/#sequence While this may seem like a simple change at first, it causes problems when documents are served as XHTML+RDFa vs. HTML5+RDFa. Rationale: It has been a goal of the RDFa WG to try and have the same processing rules apply to all versions of HTML - HTML4, XHTML1, HTML5 and XHTML5. Making this change in HTML5 would mean that processors would have to know whether or not they are processing an HTML5 document, or a non-validating HTML4/XHTML1 document. In certain situations, such as when an XHTML document is served with the text/html media type, it is impossible to tell which type of document you are processing. The same is true for documents that do not have the DOCTYPE or the namespace information declared on the HTML element. There are many factors that would make it impossible for RDFa Processors to know whether or not they should parse in XHTML1 or HTML5 mode. There are a few ways that one can support this feature in their RDFa Processor, however. When designing RDFa, we were very careful to make sure that there was a concept of a default graph, which held triples that all processors MUST produce. The RDFa Processor, however, can also contain a separate graph that produces additional triples. Thus, a conforming processor could always generate the datetime-based triple in a separate processor graph. The problem with this approach is that sometimes the contents of the example listed would generate the following triple: DEFAULT_GRAPH: <> dc:modified "October 29th 2010" . However, RDFa Processors that recognized @datetime would generate the following: DEFAULT_GRAPH: <> dc:modified "October 29th 2010" . SPECIAL_HTML5_GRAPH: <> dc:modified "2010-10-29T15:36:24"^^xsd:dateTime . The one thing that we can't have is some processors generating this: DEFAULT_GRAPH: <> dc:modified "October 29th 2010" . while other processors generate this: DEFAULT_GRAPH: <> dc:modified "2010-10-29T15:36:24"^^xsd:dateTime . That would create an interoperability nightmare between RDFa in HTML5 and RDFa in every other language that doesn't have a @datetime attribute. The only way to get around this issue is to introduce the @datetime attribute to every language that uses RDFa. It is not clear whether or not this would be a good idea at this time. This means that HTML elements like <object> and <video> and <body>, and many other non-HTML elements in SVG, ePub and ODF, would have a @datetime attribute - which would not make sense, and for that reason, would probably be rejected outright by the various standardization groups managing XHTML, HTML, SVG, ePub and ODF. We do agree that this would be a nice feature in HTML5. Unfortunately, for the technical reasons listed above, we cannot safely introduce this feature.
I think I understand: processors cannot be required to know that they are processing HTML5, or it is awful to contemplate adding special processing modes to processors. I like the idea of an RDFa processor knowing enough to understand time's @datetime property, and there is nothing it the specification that prevents an implementation that does this. I think that everyone will understand why markup such as <time datetime="2010-10-29" property="dc:modified" content="2007-01-01"> is likely to confuse people and should be avoided. The same can be said of markup such as <time datetime="2010-10-29">December 31 1969</time> -- perfectly valid, and a formal spec for XML should not be distorted in an attempt to avoid such. Thanks for looking at this!
mass-move component to LC1