The DP stack is getting the attention it deserves. While it would be
great to have the credibility of W3C on our sides I think DP should
remain independent until at least a solid 1.0 style release of the stack
has been done.
As suggested, Tim should be joining this workgroup as a representative
I think the response should be "WAIT"
Ben Metcalfe wrote:
> I think this is at best a pointless move and at worst a really bad idea.
> One of the criticisms of many observers about the DP.org group was
> that "it was just like the W3C and would get nothing done". Well, we
> will get stuff done, but if the group joined the W3C then... well, it
> would be just like the W3C and much of the other shit that goes with
> it - increased red-tape, etc.
> But I also think it could be a bad move because membership of W3C
> groups is limited to W3C members (which is how it pays for itself).
> Harry made some point about Chris not having to be a member, but it's
> not clear whether the group would be open to just anyone to join
> formally. I'd be concerned that whilst Google and maybe Facebook are
> members of the W3C, other companies and startups are not. We'd miss
> those folks.
> I just don't see what joining the W3C brings us. And if Tim BL
> thinks that we're doing some valuable work then I would love to
> extend to him an invitation to join *this* group.
> On Jan 15, 2008 8:21 PM, Chris Saad <chris...@gmail.com
Re. Membership - it isn't necessary for someone to be working for a
W3C member company to be on a Working Group, there's the Invited
Expert mechanism. This has been used for the HTML group -
# 499 group participants,
# 499 in good standing,
# 72 participants from 28 organizations
# 427 Invited Experts
I'd also note that DP already has two tiers, the DP list and the public lists.
Re. Getting Things Done - I don't know where the idea that the W3C
doesn't get things done comes from, half the specs we use on a daily
basis have come through the W3C.
As a recent concrete example, the GRDDL WG (of which Harry was chair)
took just over a year to tackle a fairly tricky generic problem (the
automatic conversion of microformats-style HTML and *any* XML to RDF).
While this may seem a long time, the deliverables include two
Recommendations (the main spec and test cases) together with two Notes
(primer and use cases). Concurrent with this, 4 independent
implementations were developed in the community, acting as test
The GRDDL group was a regular Working Group, but Harry's proposal is
for an Incubator Group, and they're expressly designed to get things
The W3C Incubator Activity fosters rapid development, on a time scale
of a year or less, of new Web-related concepts. Target concepts
include innovative ideas for specifications, guidelines, and
applications that are not (or not yet) clear candidates as Web
standards developed through the more thorough process afforded by the
W3C Recommendation Track. Advantages of the Incubator Activity
* Rapid start of work in an Incubator Group (XG)
* Lightweight process, initiated by W3C Members
* Rapid finish to produce an XG Report in under one year
* Smooth transition to the W3C Recommendation Track, if desired and approved
* Use of W3C infrastructure (mailing lists, communications tools,
Web site) and consensus-building within W3C culture.
> 1. What sort of involvement would you like to see from the W3C?
I like the Incubator Group idea, I believe it could help this group a
lot. It offers a coherent framework in which the development of
guidelines and resources needed for DataPortability can take place,
without messing up what we've got already.
Ad hoc development is good, but lasting solutions need some formal
basis as well. We do need to maintain compatibility with existing
specifications wherever possible, we need to be sure there aren't
obscure legal issues waiting to trip everything up. The DP group may
have the technical expertise to get work done, but it simply doesn't
have the resources of a standards org.
This can happen without disrupting what we've got already.
The WHAT WG is doing fine since it's 'merger' with the W3C HTML group,
and that's quite an extreme case - browser vendors are big
stakeholders in that community, and their aims don't necessarily
coincide with what's best for (users of) the Web.
Although they went with the IETF rather than the W3C, the Atom working
group is a good example of how a community project can benefit from
what a standards org has to offer. It was able to get significant
input from a broad range of sources, keep focus on what was needed and
reach consensus, without losing its community roots.
> 2. Would such involvement:
> a) Unnecessarily slow down the process we have started here?
I believe it will speed things up, by helping us to be clearer about
aims and having a process for ensuring decisions are made that are
consistent with these.
> b) Add weight to DataPortability and improve our decision making going
Yes. While this group has significant support from key players around
social networks, to anyone directly not involved, this group can be
perceived as a "ragbag" (see http://blogs.zdnet.com/Howlett/?p=277).
Association with the W3C will show the group's proposals as credible
to the enterprise and other potential users of the technology.
I should add that while I'm more than happy to go with consensus as
far as this group is concerned, I do also support Harry's proposal for
a W3C Incubator Group, even if it would have to operate completely
indepedently of this group (well, I doubt it would be completely
independent, there would be bound to be some crossover no matter
Of course ideally everyone will be working together on what are
seriously important issues. But because of the importance of the
issues, I do think it necessary for the W3C to consider them,
irrespective of any community initiatives like ours, as part of it's
stated goal of "leading the Web to its full potential".
Bear in mind, agreements like these can be nightmares to get approved
in large organizations, since typically employees cannot sign a legal
document without the legal team's approval.
I think they are definitely good in the long run, but I'd hate to see
in the short term having people's participation stalled based upon it.
Perhaps it might make sense to keep the overall DP Working Group as a
more ad-hoc institution, but as more concrete deliverables emerge,
moving some of the technical standards finalization into more formal
W3C groups over time.
W3C participation is also more significant for certain parts of what
the group wants to accomplish (e.g. technical standards) and less so
for things like best practices documents.
(In addition, part of the strength of the group now is the speed with
which we can try new things out and iterate on them, prior to making
It should be noted that the W3C is a standards body, not a person or
company - i.e. it is composed
insitutitions like companies, and so it can in general only do things
its members ask for.
It does have a small paid staff, but after conversation with Ivan
Herman, it does appear they are all tied up with other standards work,
although they are very supportive of DataPortability.org. So, it's
unclear if a W3C staff member can actively contribute to
DataPortability.org. Right now I just chime in and e-mail Ivan and W3C
staff when something interesting is going on so it stays on their
W3C Staff can only justify using their staff resources if the member
institutions indicate they want this to go forward.
Ivan and myself thought an "Incubator Group" would be the most "low-
budget" way to show this, as well
as to make sure going-ons here get forwarded to the right people in
the W3C. The "Incubator Group" would basically
have a year to monitor developments on the Web at large (including
DataPortability.org) and then would propose
that the W3C officially, if needed, fast-track a Rec. on this topic.
Again, any thoughts?
I would argue against using the W3C because they represent their
member institutions rather than being open to all.
I also don't get this obsession with standards bodies - if a group of
people agree that it is a standard, then it is a standard.