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: Thu, 14 Mar 2013 08:51:38 +0100
Cc: RDFa WG <public-rdfa-wg@w3.org>
Message-Id: <90654B3C-84C9-4A91-91DA-FF26390DB307@w3.org>
To: Manu Sporny <msporny@digitalbazaar.com>

I have looked at the status section of the draft, I made a tiny change and added a sentence.

There are two features in this specification, @datetime processing and rdf:HTML literals, that are currently defined as non-normative features. The intent is that these features will eventually become normative features once the specification that describes the @datetime attribute [HTML5] and the specification that defines rdf:HTML [RDF-CONCEPTS] become W3C Recommendations. Implementers should implement these features now; a 2nd (or later) edition of this specification will clarify the long-term stability of those features.

Based on the discussion between the RDFa Working Group and the HTML5 as well as the RDF Working Groups, it is not expected that implementation changes will be necessary as HTML5 and RDF 1.1 advance to Recommendation.

I think we can go to Ralph & Thomas with this...

I also see that you removed the 'at risk' aspect of property copying. I personally agree with this, but that still requires a WG decision:-)... B.t.w., I have asked DanBri lately for a google comment on specifically this feature.



On Mar 13, 2013, at 05:01 , Manu Sporny <msporny@digitalbazaar.com> wrote:

> On 03/12/2013 01:53 AM, Ivan Herman wrote:
>> 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. 
> Yep.
>> - I can see your point on the <link>/<meta> issue.
> Good. :)
>> - I think we still have other references we make into the HTML5
>> document (algorithms) that should be cross-checked for stability.
> I'll make another pass tomorrow, but I'm fairly certain I already did
> this. That is, we can't call out the entire HTML5 parsing/re-parenting
> algorithm because it is gigantic, complex, and would make the whole spec
> optional. It has multiple stable browser implementations, and is as
> stable as we can expect anything in HTML5 to be.
>> - 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. 
> I don't think it's useful to point to the process document in this
> instance. I think it's more useful to point to why the process document
> says what it says: to ensure implementation stability. I think either
> approach achieves the intended protection that the W3C process is
> attempting to achieve (stability). I also think that W3C has already
> done something like this before HTML5 (OWL2), and that rule is the one
> that needs to be generalized to all specs. HTML5 isn't really special in
> that respect... but we could spend weeks arguing the finer points of this.
> I've taken your advice in the latest spec and just marked the features
> as "non-normative" with an explanation in the SoTD about when the
> features are expected to become normative. I think this is what you
> wanted. The wording is a bit rough right now, so any suggestions on how
> to clean it up would be appreciated:
> http://www.w3.org/2010/02/rdfa/sources/rdfa-in-html/Overview-src.html
> To view a diff-marked version do: CTRL-ALT-SHIFT-S and click 'diffmark'
>> 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.
> +1
> -- 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 Thursday, 14 March 2013 07:52:07 UTC

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