jodyer at adobe.com
Sat Feb 16 16:06:09 PST 2008
Thanks for your comments and questions. I¹ll try to address them here, and
hopefully you¹ll be able to join us on the next Tuesday phone call so we can
further flush out the issues.
> ³1. What actually are the proposals?²
> ³Many of those proposals on the Wiki are dated and much water has gone under
the bridge on these proposals since they were first made. Many conversations
have been had with sometimes subtle and sometimes not so subtle changes to the
meaning of those proposals. This presents a real problem for implementers in
understanding exactly what has been proposed and what is the meaning of the
proposals. For those who were present in those conversations and meetings may
have it all committed to memory, but those who have not present will certainly
struggle to gain a clear and exact understanding, as I do.²
You are correct in saying that the proposals don¹t all stand on their own.
This is the problem we intend to solve by requiring production
implementations to support complete and accurate feature specifications.
Each proposal carries with it a significant context, more or less captured
in meeting notes, trac tickets, the RI, and various people¹s heads. The
implementation focus will have two important effects: 1/force the
translation of proposals (by those with the necessary context to do so) into
implementations and feature specs that will stand on their own; 2/give
everyone else specific interpretations of those proposals to respond to.
> ³So my question is what are the agreed set of proposals and where are they
The agreed set of proposals are the ones posted on
http://wiki.ecmascript.org. Adequate documentation is what we intend to
produce, along with the all important agreement about what can and should be
implemented in our products. Admittedly we have a bit of a bootstrapping
problem here: we need to implement to know what we have agreed to, and we
need to understand what we agreed to to implement. But with the right people
working together I am confident that this cycle can be broken.
> ³A related question that exacerbates this problem is what has become of the
discussion to trim / streamline some of the feature set. As implementers, we
don't want to spend time implementing features that are not likely to be in the
An important side effect of an implementation focus is the prioritization of
features. There is a core set of well understood features that I believe we
need to include for the language to support itself (e.g. the built-ins). On
the other hand most of us have a list of features we could live without, or
believe are not sufficiently baked to qualify for standardization. Those
lists should be shared and guide our individual investments in
implementation, but I don¹t think they should take priority over real world
experience implementing and using the language. And I absolutely don¹t want
to spend my time debating the content of those lists until we have
implementation and user experience to ground that debate.
A huge amount of time and (inspired) effort has gone into creating the
current set of proposals. We need to be careful to protect that investment
by following a process that allows viable features to take root and others
to naturally wither and die.
As early implementers we necessarily run the risk of implementing features
that don¹t make it into the standard. On the other hand, we learn before
others what works and what doesn¹t. Again the point of this exercise is to
leverage that experience to get the language as close to right as possible.
> ³2. The RI is a key implementation too.
In your work flow, the RI seems to lag the implementations and you say it
has a role in prototyping features. But it has been filling a crucial role
in clarifying what the proposal was really meant to do. This goes beyond
prototyping. I regard the RI as the first implementation and the last. The
first, in the sense that it should define how the features are meant to
function and guide implementers and prevent many blind alleys. The last in
the sense, that it defines the spec. I'd like to stress that it must
continue to lead in implementing all key features.²
Admittedly I was doing a little hand waving here. Clearly the RI has given
us early insight into the language design, forced issues to the surface
sooner rather than later, and given us a model to play with. And in terms of
feature scope, the RI is fairly complete (thanks mostly to Graydon). The
point of the workflow is to show when key milestones are reached. In this
end game plan, here really isn¹t a clear and useful milestone associated
with the initial implementation in the RI. We could define one but that
might just add unnecessary overhead to the process. I see the current RI as
a part of that bundle of materials we call Proposals.
>²Your timeline below does not indicate the kind of implementation readiness you
need to make this work flow actually work. Can you detail what kind of
implementation feedback you need?²
Two questions come to mind:
1 do you understand the feature well enough to write a detailed
specification of it?
2 are you willing to ship it as is (modulo bug fixes and performance
>²Lastly, please don't interpret the above 2 issues as negative feedback. I
think this is a good and normal process for defining a spec. We need to have
real-world experience using these features to prevent painful errors going
Thanks, no offense taken. On the contrary, I see the advanced ES4
implementation work you have done as a great asset that we need to leverage.
The process outlined here can be used by those with shared values and vision
to produce a strong specification that defines the language of multiple
implementations. It needs further refinement, but mostly it just needs to be
On 2/15/08 11:20 PM, Michael O'Brien wrote:
> Thanks for outlining the process to go forward. Overall I like having real
> implementations prove the value and feasibility of features and proposals
> before they are poured in concrete. But I see 2 2 obstacles that I outline
> 1. What actually are the proposals?
>> Many of those proposals on the Wiki are dated and much water has gone under
>> the bridge on these proposals since they were first made. Many conversations
>> have been had with sometimes subtle and sometimes not so subtle changes to
>> the meaning of those proposals. This presents a real problem for implementers
>> in understanding exactly what has been proposed and what is the meaning of
>> the proposals. For those who were present in those conversations and meetings
>> may have it all committed to memory, but those who have not present will
>> certainly struggle to gain a clear and exact understanding, as I do.
>> I've been using the RI, Lars's paper and emailed questions to flesh out my
>> understanding of the proposals -- but my understanding is often incomplete or
>> So my question is what are the agreed set of proposals and where are they
>> adequately documented?
>> A related question that exacerbates this problem is what has become of the
>> discussion to trim / streamline some of the feature set. As implementers, we
>> don't want to spend time implementing features that are not likely to be in
>> the final spec.
> 2. The RI is a key implementation too.
>> In your work flow, the RI seems to lag the implementations and you say it has
>> a role in prototyping features. But it has been filling a crucial role in
>> clarifying what the proposal was really meant to do. This goes beyond
>> prototyping. I regard the RI as the first implementation and the last. The
>> first, in the sense that it should define how the features are meant to
>> function and guide implementers and prevent many blind alleys. The last in
>> the sense, that it defines the spec. I'd like to stress that it must continue
>> to lead in implementing all key features.
> Your timeline below does not indicate the kind of implementation readiness you
> need to make this work flow actually work. Can you detail what kind of
> implementation feedback you need?
> Lastly, please don't interpret the above 2 issues as negative feedback. I
> think this is a good and normal process for defining a spec. We need to have
> real-world experience using these features to prevent painful errors going
> Michael O'Brien
> Mbedthis Software
> Jeff Dyer wrote:
>> We have entered a new phase in the development of the ES4 standard. Since
>> September we have had a fixed set of proposals to consider individually and
>> as a whole. The final step is to translate those proposals into production
>> implementations and to document the language that results to become the next
>> ES standard.
>> What follows is a high level description of the process that we (Adobe and
>> Mozilla) feel should be followed to get from Proposals to a high quality,
>> finished specification.
>> We should discuss this at our ES4-WG phone call this Tuesday (Feb-19).
>> Advanced comments welcomed.
>> The basic workflow:
>> Proposal -->
>> Implementation -->
>> Feature spec -->
>> Feature review -->
>> ES4-RI -->
>> ES4 spec -->
>> Proposal - see http://wiki.ecmascript.org/doku.php?id=proposals:proposals.
>> These proposals are the pool of possible feature proposals. Only exceptional
>> circumstances will warrant a feature not covered by an accepted proposal to
>> be considered.
>> Implementation - interested implementers collaborate on the implementation
>> of a feature described by the proposals. This exercise should end with one
>> or more implementations of the feature to provide feedback on usability and
>> implementation complexity.
>> Feature spec - one of the participants from the implementation team writes
>> up a description of the feature based on that implementation. Feature specs
>> are complete and accurate descriptions of individual features to be added to
>> the language. They are supported by production implementation, test cases
>> and implementer commitment to release the feature.
>> Feature review - ES4-WG reviews the feature spec and implementation and when
>> satisfied accepts the spec to be included in the ES4 spec.
>> ES4-RI - once accepted, the RI is checked for compatibility with the
>> production implementation and readability. Although the RI is used as a kind
>> of prototype of the proposals, its primary purpose is aide in understanding
>> and exposition of the language. This step involves preparing parts of the RI
>> for inclusion in the spec.
>> ES4 spec - and finally, the ES4 draft is updated to include the accepted
>> feature and reviewed first by ES4-WG and then TC39.
>> IMPLEMENTATION TEAMS
>> The implementation teams will be ad hoc collaborations between two or more
>> implementers. Ideally, at least one of those implementers is an Ecma member
>> so that the feature has representation throughout the standardization
>> ES4-WG AND TC39 MEETINGS
>> The ES4-WG meetings should focus on the review of feature specs and ES4 spec
>> drafts. Two weeks before each TC39 meeting a draft of the ES4 spec will be
>> distributed for review by the TC39 members.
>> In order to be approved at the December 2008 GA, a final draft of the ES4
>> spec must be ready for review at the Sep TC39 meeting. This is clearly an
>> aggressive schedule, but one that is achievable given that high quality
>> feature specs are produced by several feature teams in parallel.
>> We envision at least two teams working in parallel on AS3-like features and
>> JS1.7-like features.
>> Here is a very high-level schedule of deliverables to TC39
>> Mar - draft 1
>> - ES3 spec based on the ES4-RI
>> - Library spec
>> May - draft 2
>> - Core language mostly spec-ed
>> Jul - draft 3
>> - Spec complete
>> Sep - draft 4
>> - Final review
>> Oct - final draft
>> - Send to CC for approval
>> Es4-discuss mailing list
>> Es4-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Es4-discuss