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

Re: HTML+RDFa 1.1 PR Transition Paperwork

From: Ivan Herman <ivan@w3.org>
Date: Tue, 12 Mar 2013 06:53:25 +0100
Cc: RDFa WG <public-rdfa-wg@w3.org>
Message-Id: <13649445-A878-457B-BBBC-FF95841FFD79@w3.org>
To: Manu Sporny <msporny@digitalbazaar.com>

I think, in any case, that we will have to contact Thomas and Ralph informally with the solution we are proposing before we issue a formal transition request. These are my personal comments, thus, the final arbiter should be those old wise men of the process:-)

- I can see your point on the <link>/<meta> issue.

- I think we still have other references we make into the HTML5 document (algorithms) that should be cross-checked for stability.

- However, I do not think the RDFa 1.1 dependence issue will fly. The process is fairly clear on that issue: a Rec cannot normatively reference a document that is not a Rec itself. Due to the particular nature of HTML5 an exception to the rule has been defined, but that does not apply to RDF 1.1. (I would not worry about the management agreeing in keeping the WG in a dormant state. That is only an admin issue, it is done that way to keep the IPR statements valid; as long as the group does not use resources, it is not a problem.)

As you say, HTML and or @datetime, are nice-to-have issues, so having them as informal features right now, with a clear statement as for the intention to become formal in a few years, is enough for the stability of the spec in practice. All our tests already incorporate these, all our implementations already do these. The work to be done in a few years will be a breeze, an admin issue that can be handled by you as editor (or anybody else, actually, who would take up that role) and the Semantic Web activity lead of the time. (I have seen the way it was done for OWL and RIF; as I said, the only reason it was a bit more complicated was because the document processing mechanism was more complex, and there were a large number of affected documents...)



P.S. We will probably give more details on the implementation part, because we are actually requesting jumping over a step. But that is a detail.

On Mar 12, 2013, at 04:45 , Manu Sporny <msporny@digitalbazaar.com> wrote:

> Hi all,
> I've started documenting the PR Transition Paperwork here:
> http://www.w3.org/2010/02/rdfa/wiki/Html-rdfa-1.1-pr-overview
> 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
>   years.
> 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
> http://manu.sporny.org/2013/payswarm-journals/

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 Tuesday, 12 March 2013 05:53:55 UTC

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