- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Wed, 31 Mar 2010 11:13:14 -0400
- To: HTMLWG WG <public-html@w3.org>
- CC: RDFa WG <public-rdfa-wg@w3.org>
On 03/31/10 05:07, Henri Sivonen wrote: >> The only reason we are decoupling HTML+RDFa LC from HTML5 LC is in >> the >> case that there is some significant last-minute change to HTML5 that >> requires the RDFa WG to go back and rework HTML+RDFa. > > You seem to writing as though the RDFa WG were developing HTML+RDFa > if it's the WG to potentially "rework" it. (RDFa WG co-chair hat on) I can see how that could have been misconstrued as "The RDFa WG is really the one that is responsible for developing HTML+RDFa." Let me be very clear that it is not. It would have been far better if I had said "go back and rework RDFa Core 1.1 and help to modify HTML+RDFa, while working hand-in-hand with HTML WG, to follow any significant changes in HTML5". The assumption was that HTML WG and RDFa WG are working together, in good faith, on these documents. So, in an attempt to be crystal clear: 1. RDFa WG is working on RDFa Core 1.1 and is the responsible publishing body for that document. RDFa WG actively seeks input from HTML WG on all documents that it is creating. 2. HTML WG is working on HTML+RDFa and is the responsible publishing body for that document. RDFa WG is actively providing input on that document. 3. It has been demonstrated that both HTML WG and RDFa WG are capable of working together on HTML+RDFa (because there have been a number of changes in RDFa Core and the last HTML+RDFa heartbeat draft that were a direct result of input from HTML WG). 4. HTML WG has full control over HTML+RDFa - which means that they can add/remove/modify features described in RDFa Core 1.1. Please read #4 again, because that's the most important one, and I want to be very clear about this. HTML WG has /full control/ over HTML+RDFa, just like it has full control over the HTML5 specification and the Microdata specification. > http://www.w3.org/Bugs/Public/show_bug.cgi?id=7670#c43 says "So, any > changes made to RDFa Core 1.1 will be applied to HTML+RDFa.", which > seems to mean that HTML+RDFa is so constrained by the output of the > RDFa WG that there isn't anything for the HTML WG to do except to > rubber-stamp it. (After all, bug 7670 is about one of the central > concerns raised about RDFa in the HTML WG.) I can see how you may have come to that conclusion, but that's not the intent, nor can I see that as a workable solution, nor do we desire that to happen. To elaborate further, /if/ HTML WG decides to ban the use of xmlns: in HTML5 documents outright, break backwards compatibility with RDFa 1.0, as well as reject the concept of indirection mechanisms in markup, the HTML WG could: 1. Modify the HTML+RDFa specification to remove support for xmlns:. 2. Modify the HTML+RDFa specification to remove indirection mechanisms in markup. 3. Modify the HTML+RDFa specification to modify the processing rules outlined in the RDFa Core document to only allow a subset of RDFa Core functionality. The RDFa WG hopes that HTML WG doesn't make HTML+RDFa deviate that greatly from the RDFa Core specification as to effectively break markup compatibility with SVG, XHTML1.1+RDFa 1.1, and ODF... but that control, power and capability is entirely in the purview of the HTML WG. > What's the point of making HTML+RDFa nominally a deliverable of the > HTML WG or making SVG+RDFa nominally a deliverable of the SVG WG if > RDFa Core is fully(?) constraining what these specs can say? There is no point to doing that - which is why we're not doing that. > Why > aren't HTML+RDFa and SVG+RDFa direct deliverables of the RDFa WG if > the RDFa WG is de facto defining the normative constraints on the > specs? HTML+RDFa is a direct deliverable of HTML WG. HTML WG has the authority to override any part of RDFa Core 1.1 that it wants to override via HTML+RDFa. SVG+RDFa can be a direct deliverable of SVG WG (if they so desire). SVG WG has the authority to override any part of RDFa Core 1.1 that it wants to override via SVG+RDFa. The same goes for all of the "thin" language specifications that layer on top of RDFa Core. Does that make things more or less clear? Have your reservations been addressed? -- manu -- Manu Sporny (skype: msporny, twitter: manusporny) President/CEO - Digital Bazaar, Inc. blog: PaySwarming Goes Open Source http://blog.digitalbazaar.com/2010/02/01/bitmunk-payswarming/
Received on Wednesday, 31 March 2010 15:13:46 UTC