Re: Working Group Decision on ISSUE-120 rdfa-prefixes

On 04/06/2011 05:00 PM, Sam Ruby wrote:

> We received exactly two change proposals:
>
> http://wiki.whatwg.org/wiki/Change_Proposal_for_ISSUE-120
> http://www.w3.org/html/wg/wiki/ChangeProposals/RDFaPrefixesNoChange
>
> Nobody brought forward a change proposal that matches what you describe.
>
> If you wish to do so at this time, please provide new information such
> as they types described in the decision itself as well as a complete
> change proposal.

I believe that the following things represent information that was new 
to me compared to the time the change proposals were originally written:

1) A substantial fraction (possibly the majority, although this is an 
inference) of *all* deployed RDFa on the web is OpenGraph API targeted 
at Facebook (I infer this from the fact that the increase in the use of 
RDFa has coincided with the deployment of the OpenGraph stuff and the 
fact that it is the biggest consumer of RDFa that doesn't also accept 
microformats or microdata.

2) The Facebook implementation of "RDFa" is entirely non-conforming with 
regard to prefixes. It simply treats properties as (prefix, name) tuples 
instead of (uri, name) tuples. If the prefix matches the property is 
processed, otherwise it is ignored. As a collary, prefixes used by 
facebook are effectively unusable in other content that is not intended 
to provide OpenGraph data.

3) There is deployed content that depends on this behavior.

Given the above, it is difficult to see a path by which the current RDFa 
spec can be made to match reality. Specs that don't match reality are 
not useful and I don't think we should be producing them. If I had 
realized the seriousness of the problem at the time of the original 
poll, I would have advocated a change proposal something like the following:

* For use in HTML documents, RDFa property prefixes MUST be registered 
using a lightweight (e.g. wiki based) registry similar to rel values

* Tools processing RDFa in HTML MUST NOT use any in-document mechanism 
to bind prefixes to URIs, but instead MUST only recognise prefixes as 
they are registered (obviously they need not recognise all prefixes 
registered at a given moment).

* For compatibility, authors MAY put xmlns declarations corresponding to 
prefixes in the document. If they are so used they MUST match the 
bindings that would be produced from the registered prefixes.

Do the chairs consider the above information sufficiently novel to 
consider reopening the issue were a change proposal to be submitted? If 
not, I see no point in wasting my time on writing one.

>> Do the chairs intend to respond to my request for clarification about
>> the decision?
>
> General statement: publication of Working Group decisions indicate the
> point at which the co-chairs have determined that the Group has duly
> considered the legitimate concerns of dissenters as far as is possible
> and reasonable, and that the group SHOULD move on[1]. I believe that you
> understand the need for this[2].

Indeed. I also believe that it is not in the best interests of the group 
for the chairs to silently ignore queries about how decisions were 
reached. In particular I don't think that answering reasonable enquiries 
prevents the group from moving on. If the reasonable enquiries become a 
larger volume of discussion without new information it is of course 
appropriate to halt that discussion.

> We invite new information to be provided. Alternately formal objections
> can be raised at this time; and if raised we will record them[3]. Any
> such objections will be evaluated by the appropriate people at the
> appropriate point in the process.

I personally don't see that raising formal objections is very useful. 
The timescales for FOs to be acted on are too long to provide oversight 
on the activity of the chairs. The people considering FOs are further 
removed from the technical details of the issues than people in the WG 
which makes it seem unlikely that, on average, they will make better 
decisions.

Received on Thursday, 7 April 2011 11:07:38 UTC