Request to reopen ISSUE-120 rdfa-prefixes (was: Working Group Decision)

On 04/07/2011 07:07 AM, James Graham wrote:
> 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 reality can  be
> made to match the current RDFa spec. 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.

First, as background, we did agree to reopen[1] issue-30 based on new 
information.  Note that we did NOT do so on the basis of "new research".

As cited by the decision on issue-120[2], the fact that existing 
implementations have bugs (as in deviations from the current draft 
specification) is not new information.  We also would not consider as 
new information any speculative inferences as to the intent of the 
authors of these tools or speculation as to what their future plans 
might be.  In the list above, what *might* be considered sufficient new 
information is the identification of a significant amount of deployed 
content that depends on these bugs, depending on the magnitude of such data.

Additionally we would find the following to be "sufficiently novel": 
multiple first hand statements from people who are implementing distinct 
large scale RDFa consuming tools on how they would prefer to proceed.

If this is something that you wish to pursue, we suggest that you reach 
out the tool authors.  Open bug reports pointing out the deviations from 
the current spec and ask for input.  Do so openly and jointly with the 
involvement of the authors of the current HTML+RDFa draft.

If you were to do that, and provide a Change Proposal based on that 
data, we would agree to evaluate your "new information" and decide if 
the issue should be re-opened as a Last Call issue.  Be aware that we 
would not plan to put out a call for Alternate or Counter Proposals any 
earlier than late May.

We encourage you to take your time.  Just like we cautioned the folks 
who requested that issue-30 be reopened, we will warn you that reopening 
any issue will significantly raise the bar for similar requests in the 
future.

- Sam Ruby, on behalf of all three co-chairs

[1] http://lists.w3.org/Archives/Public/public-html/2011Mar/0037.html
[2] http://lists.w3.org/Archives/Public/public-html/2011Mar/0689.html

Received on Sunday, 10 April 2011 00:39:51 UTC