[Bug 11169] HTML+RDFa - Infer @content from @datetime on time tag

http://www.w3.org/Bugs/Public/show_bug.cgi?id=11169

Manu Sporny <msporny@digitalbazaar.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WONTFIX

--- Comment #1 from Manu Sporny <msporny@digitalbazaar.com> 2010-12-04 18:10:23 UTC ---
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.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Saturday, 4 December 2010 18:10:26 UTC