Hi All,

Wow! The amount of email on Web IDL over the last few days has been amazing!

I am wondering out loud here if it would make sense to split up the Web IDL spec? For example, a functional split e.g. the IDL in one doc, ES 3/5 bindings in a separate doc, Java bindings in a separate doc, etc. Or a core/non-core (e.g. L1/L2) split (I think Maciej used the term "simplification" in one of his emails). Perhaps there is some other split that would be useful.

OTOH, splitting specs can create other problems such as synching the specs, increased overhead for the Editor(s), communication (at least 3 WGs plus TC 39), etc.

WDYT?

-Regards, Art



Begin forwarded message:

From: ext Robin Berjon <ro...@berjon.com>
Date: September 28, 2009 5:02:38 AM EDT
To: "Mark S. Miller" <erig...@google.com>
Cc: public-webapps WG <public-webapps@w3.org>, es-discuss <es- disc...@mozilla.org> Subject: Re: Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination) Archived-At: <http://www.w3.org/mid/ 0b16970c-4738-4060-83a0-49d106b6c...@berjon.com>

On Sep 27, 2009, at 21:44 , Mark S. Miller wrote:
On Sun, Sep 27, 2009 at 12:35 PM, Robin Berjon <ro...@berjon.com>
wrote:
I would tend to be rather in disfavour of anything that might cause
WebIDL to be delayed in any way. I also think that keeping the ES3
binding is useful (in the short term at least) if only because it is
familiar,

This seems like a standard without an audience, as ES5 is becoming
official well ahead of HTML5. Who needs HTML5 on ES3?

I'm not sure what you're getting at here. WebIDL isn't just for HTML5,
it's used throughout WebApps and DAP, and by a number of other groups
as well, which have deliverables at various levels of completion. By
depending on WebIDL, a lot of these cannot move forward along the
process until WebIDL itself moves ahead.

Don't get me wrong, I'm not in the least hostile to an ES5 binding. I
just don't want to rush into it and have a knock-on effect on the
timeliness of a bunch of other people's work.

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






Reply via email to