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

HTML+RDFa 1.1 PR Transition Paperwork

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Mon, 11 Mar 2013 23:45:00 -0400
Message-ID: <513EA4BC.9020304@digitalbazaar.com>
To: RDFa WG <public-rdfa-wg@w3.org>
Hi all,

I've started documenting the PR Transition Paperwork here:


While working on the page, I've come to believe that we're taking the
wrong approach for the datetime and rdf:HTML support. I also believe
that Mike Smith(tm)'s change is not a substantive change per the W3C
definition of a substantive change. That said, I don't think the group
needs to go through a 2nd Last Call. We still need to pass this logic by
Ralph and Thomas. Here are the arguments:

datetime and rdf:HTML support

I think we should put a statement in the "Status of the Document"
section stating that the HTML5 datetime support, and the rdf:HTML
support is normative, but not finalized in the normatively-referenced
specifications. If the features end up not being supported, a correction
will be made in the errata of the HTML+RDFa 1.1 specification, so
implementers should check those from time-to-time to ensure that they
have not been removed. Those errata will be merged into a future
HTML+RDFa 1.1 PER, but that PER doesn't have to be created by the
current RDFa WG.

This has the advantages that:

1. The RDFa WG can end in June, we won't have to convince the W3C
   AC to hibernate but extend the RDFa WG charter by months if not
2. In the very worst case, the specification can be corrected in the
   errata and the test suite updated to match.

In other words, I think we're over-thinking this a bit too much. These
are nice-to-have features (@datetime and rdf:HTML) that will not break
HTML+RDFa 1.1 even in the very worst case... and even then, they are
easily corrected.

The W3C needs a unified way of supporting specs that are capable of
safely going to REC in these sorts of scenarios. In the very least, we
should ask Ralph and Thomas if this is a reasonable path forward.

Narrowing validity for LINK and META

The other change we made makes the <link> and <meta> elements only valid
in the body of an HTML5 document if @property also exists in those
elements. Some argued that this is a substantive change to the HTML+RDFa
1.1 Last Call document. After reading the W3C documents on the matter, I
disagree. Here's the definition from W3C's Process document:

A substantive change (whether deletion, inclusion, or other
modification) is one where someone could reasonably expect that making
the change would invalidate an individual's review or implementation
experience. Other changes (e.g., clarifications, bug fixes, editorial
repairs, and minor error corrections) are minor changes.

This change does not affect any of the RDFa Processor implementations.
It is specific to an HTML5 Document Validator. The change does not
invalidate Mike Smith(tm)'s implementation experience but is a product
of input from him. Thus, this change should be categorized as either a
"bug fix" or a "minor error correction", not a substantive change.


If these arguments hold then we don't need to go through a 2nd LC for
HTML+RDFa 1.1 and we've solved the problem of taking HTML+RDFa 1.1 to
REC with a more light-weight approach for this group and for W3C.

-- manu

Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: Aaron Swartz, PaySwarm, and Academic Journals
Received on Tuesday, 12 March 2013 03:45:31 UTC

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