W3C home > Mailing lists > Public > www-tag@w3.org > July 2011

Re: RDF Web Applications WG Position on RDFa/Microdata Task Force

From: Harry Halpin <hhalpin@ibiblio.org>
Date: Tue, 12 Jul 2011 08:46:17 -0400
Message-ID: <CAE1ny+5_zwb_BWQObMEUjZQVM40aGbu9Omkjy0+TrRH-inoL5w@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: Manu Sporny <msporny@digitalbazaar.com>, W3C TAG <www-tag@w3.org>
On Mon, Jul 11, 2011 at 2:38 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> On Mon, Jul 11, 2011 at 7:31 AM, Manu Sporny <msporny@digitalbazaar.com> wrote:
>> CONCERN: Multiple specifications for the same task
>>
>> During the TAG discussion, Larry Masinter produced a question that is at
>> the heart of the issue. "Does anyone want there to be more than one
>> structured data syntax published by W3C that accomplishes the same task?"
>>
>> In hindsight, it was a mistake for the HTML WG to allow the publication
>> of two specifications that accomplish effectively the same task (from
>> the viewpoint of the public). It is natural that nobody wanted to block
>> the work of others - but since that hard decision was not made, and
>> since some very large companies are attempting to make that decision for
>> their customers, it is creating a great deal of confusion in the
>> marketplace.
>>
>> We recommend that the question that Larry asked is required to be
>> answered by the Task Force.
>
> This does not appear to be a problem.  It seems much more problematic
> to adopt a "first-to-file" system of solving problems, where later
> attempts to solve a problem better are blocked by someone else having
> already attempted to address it.  This problem would be made somewhat
> worse by the fact that people within the W3C can fast-track their own
> solutions and produce a deliverable much faster than an outside party
> can.
>
> If the W3C does not wish to back multiple technologies, it should
> avoid pioneering in new spaces, and instead wait for the market to
> choose a winner before stepping in.  (I don't think this is a very
> good idea, mind you, but I believe it's the best solution if we insist
> on only supporting a single solution to a problem.)
>

I would also note that the real problem here is not pioneering new
work per se, but pioneering new work without the support of relevant
vendors and thus having certain technologies go down Rec track without
wide implementation or adoption. One way to fix this is the new W3C
"Community Group" process [1], which is supposed to let multiple
pioneering technologies be developed with minimal oversight in a
fast-moving process, and so we can have a separate "experimental"
phase that allows for technologies to have more time to be fully baked
and gain support.

   cheers,
      harry

[1] http://www.w3.org/QA/2011/04/coming_soon_w3c_community_grou.html


>
>> CONCERN: Scope of structured data in HTML not clearly defined
>>
>> What are the goals of the structured data in HTML work? Is it to support
>> the RDF data model? Support some other Microdata-like data model?
>> Support all of the use cases identified? Only support use
>> cases that are "mainstream" for Web developers? Provide a browser API
>> and unified view of structured data on the web? How much complexity
>> should be exposed to a beginner of structured data? If there is to be a
>> unified path forward for structured data on the Web, it is important to
>> understand which use cases we're supporting and which ones we're leaving
>> behind.
>>
>> We recommend that the Task Force identify a clear set of goals and use
>> cases that are to be supported by the structured data in HTML work. The
>> questions above are provided as suggested discussion points.
>
> This was addressed during the creation of Microdata.  The goal was to
> support the identified use-cases, which represent cases (believed to
> be reasonably common) where authors would like to solve particular
> problems related to embedding machine-readable data.
>
> Any development process not explicitly linked to use-cases for real
> authors is an anti-pattern, in my opinion.
>
>
>> CONCERN: Consensus on "No Change"
>>
>> There is a concern that the group will be provided with very difficult
>> decisions and instead of wanting to make a hard decision, they will
>> resolve to not change anything. This will be viewed as a failure of the
>> group.
>>
>> This issue is an opportunity for the W3C to demonstrate that the
>> organization is capable of finding consensus and driving positive change
>> among a broad constituency.
>>
>> We recommend that a "no change" result should not be an option for the
>> Task Force.
>
> This seems very dangerous and a bad idea.  Why do you believe that a
> "no change" decision is necessarily a bad outcome?  If may turn out
> that, after further review, there is no significant problem worth
> spending effort on solving.
>
>
>> CONCERN: Key implementers will choose to not be involved.
>>
>> It is vital that companies that have deployed, or intend to deploy,
>> structured data are active participants in the Task Force. This includes
>> having the right set of people there as well as ensuring that they are
>> committed to the work of the group. The XForms/WebForms and XML/HTML
>> Task Forces largely failed in their mandate due to inactivity by major
>> participants.
>>
>> We recommend that personnel from relevant companies are involved and
>> that those personnel have decision making power to enact change in their
>> organizations related to the Task Force findings.
>
> I support this, but probably from a slightly different view.  If
> relevant companies aren't involved, the TF will be completely useless.
>  If relevant companies don't *want* to be involved, it's an indication
> that they don't believe there's a significant problem worth solving.
>
>
>> CONCERN: Agreement followed by inaction
>>
>> It could be that there is agreement among the Task Force participants to
>> do something, but there is no follow-through. Solid commitments should
>> be made and the Task Force should follow-up to report on progress
>> regarding those commitments. Perhaps the HyperText Coordination Group
>> should play a part in this work.
>>
>> We recommend that the Task Force gather commitments to enact change at
>> the end of the discussion phase and then follow-up and report on
>> progress regarding the commitments.
>
> Same as previous.  If inaction is the ultimate result, that just means
> that the relevant companies don't feel there is a significant problem
> worth solving.  (And additionally, the time spent in the TF was
> wasted.)
>
>
>> CONCERN: TAG Note is not actionable
>>
>> There is concern in the HTML WG and the RDF Web Apps WG that the note
>> provided by the TAG is not actionable[4] without further information
>> from the TAG (formal objection or bug reports) or Task Force (findings
>> turned into bug reports). The result is that the Working Groups must
>> either ignore the TAG note until the Task Force has completed their
>> work, or halt their work until the Task Force has completed their work.
>>
>> We recommend that the TAG submit a formal objection containing technical
>> issues for both specifications, or that the TAG submits a series of bugs
>> for both HTML+RDFa and HTML+Microdata in addition to RDFa Core 1.1 in
>> the RDF Web Apps WG.
>
> Agreed that a non-actionable note without details of specific problems
> or bugs isn't very useful.
>
> ~TJ
>
>
Received on Tuesday, 12 July 2011 12:46:44 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:48:39 GMT