- From: James Graham <jgraham@opera.com>
- Date: Thu, 07 Apr 2011 13:07:05 +0200
- To: Sam Ruby <rubys@intertwingly.net>
- CC: HTML WG <public-html@w3.org>
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