W3C home > Mailing lists > Public > public-coremob@w3.org > February 2012

Re: Charter [via Core Mobile Web Platform Community Group]

From: Robin Berjon <robin@berjon.com>
Date: Wed, 29 Feb 2012 15:37:33 +0100
Cc: Tobie Langel <tobie@fb.com>, public-coremob@w3.org
Message-Id: <7BCB1BC7-9975-43F0-BB05-891AC4D7651B@berjon.com>
To: Marcos Caceres <w3c@marcosc.com>
Hi Marcos,

thanks for your feedback!

On Feb 29, 2012, at 12:31 , Marcos Caceres wrote:
>> The goal of the Core Mobile Web Platform Community Group (CG) is to accelerate the adoption of the Mobile Web as a compelling platform for the development of modern mobile web applications.
> Please drop the word "modern". It applies to all web applications ("modern" is about as meaningful as "native" :) ).  

I would rather keep stylistic changes to a minimal since that's just busy work — this is not a normative document. This is stylistic, the point being that we're not building atop ISINDEX.

>> In order to achieve this mission, the CG will bring developers, equipment manufacturers, browser vendors, operators and other relevant members of the industry together to:
> will bring -> brings together  

Charters are aspirational :) Stylistic.

>> Agree on core features developers can depend on.
> I would add "Research and" to the start of the above. Also, I think it should be defined in terms of "use cases", not features.  

No, developers may have use cases but they depend on features. Features are what interoperability is built with. And features are what we will be referencing. We can come up with use cases for other groups to create features with, but that's another aspect.

>> These will be defined by reference to a variety of other specifications from the W3C and other standards bodies.
> This seems kinda wrong… the problem, in my experience, is that there are gaps in the standards landscape itself to do certain things *as well as* in the specs.  

The idea is that where there are gaps and we think it's a problem, we start cutting off pieces from the fingers of the relevant working group members until the situation is addressed.

>> Compile related conformance test suites.
> Compile is confusing… maybe say "create"?  

I see what you mean but I'm not convinced it's all that confusing. In some cases we may create but in others we'll gather them from other sources. I think compile is correct even if some people think of it as a development operation.

>> The CG will develop a series of specifications which combine core features from web standard specifications by the W3C and other standards bodies. Multiple levels of the specification will be published and each successive level will build on the previous one by adding new features.
> I think it is premature to make the above assumption about how the group will create standards. We should first outline what the problems are, then come up with the most appropriate way to solve those problems.  

We could also backtrack a little further and agree on whether the URI to a Recommendation identifies the HTML document that contains it or whether it concerns the abstract Platonic Recommendation from a Group itself.

This is not an academic research group; our goal is to JFDI. We don't have a platform because vendors cherry-pick or don't do some things in the same ways. We define one. Then, since we can't do all at once and things evolve, we do it again.

>> High-quality, comprehensive and automated test suites are important interoperability drivers. The CG will compile accompanying test suites for each specification it releases.
> How will the CG assess "high-quality"?  

Using our brains, knowledge, experience, that sort of tool.

>> Features whose implementation is compromised by substantial obstacles (such as known security problems or patent licensing issues) will very likely not be included in a specification until the issues have been resolved.
> Won't the specification help resolve those? For example, putting a proposal to a WG that includes the IP owner on how to fix those issues.  

It could well be, and that might be a nice outcome, but we'll have to process this on a case-by-case basis.

>> Chair puts a question.
>> Chair endeavors to make decisions by consensus but is empowered to make decisions even where there are objections.
>> Chair has responsibility to ensure that all questions put to the group, all decisions, and all objections are publicly documented.
>> People who have material new information may request the Chair reopen a question.
> Editor lacking from the decision policy?  

As usual, editors can decide everything that the group does not :) That's just anti-bikeshedding common sense.

Robin Berjon - http://berjon.com/ - @robinberjon

Coming up soon: I'm teaching a W3C online course on Mobile Web Apps
Received on Wednesday, 29 February 2012 14:38:03 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:05:44 UTC