Re: The next HTML+RDFa Heartbeat

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