ES4 work
An HTML attachment was scrubbed... URL: esdiscuss/attachments/20080215/1c113e2a/attachment-0002
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
adequately documented?²
The agreed set of proposals are the ones posted on 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 final spec.²
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 tuning)?
²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 forward.²
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 done.
An HTML attachment was scrubbed... URL: esdiscuss/attachments/20080216/7d615b99/attachment-0002
From: es4-discuss-bounces at mozilla.org
[mailto:es4-discuss-bounces at mozilla.org] On Behalf Of Michael O'Brien Sent: 17. februar 2008 02:12 To: Jeff Dyer Cc: es4-discuss Discuss; TC39 Subject: Re: ES4 work
Jeff,
Responses below:
Jeff Dyer wrote:
> "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.
Still a bit of a catch 22 for implementers.
I wonder. Consider a complicated feature like classes. The basis document is the ActionScript 3 specification; it has been augmented by several proposals (for meta-level hooks and settings, for example), and classes are implemented in the RI. There are trac tickets too. What an implementation must do is to collect all these threads and provide a coherent implementation/specification pair, and that requires real work, but the groundwork has been laid by the background materials. In my opinion, an implementer who wants to take on classes will not do this in isolation, but will probably team up with at least one other implementer, and will have the attention of everyone who has been involved in the discussion in the working group.
What would help a great deal are unit tests and sample code for
how the features actually work. We've found that reading the builtins has helped in many cases.
That's good, and it makes sense, since the builtins probably constitute the largest corpus of working ES4 code at this time. Test cases would indeed help
Is there a plan to develop unit tests cases that the
implementations can use?
Adobe is dedicating some people to this task, but in my opinion it will be necessary for basic functional tests to come from the implementers who take care of a particular feature.
> "So my question is what are the agreed set of
proposals and where are they adequately documented?"
The agreed set of proposals are the ones posted on
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.
I've found the paper that Lars and others worked on to be very
helpful, but it was targeted at a broad audience. We find that we often drill down questions that are not easily answered. For example: what is the exact scope for function default parameter expressions, constructor initializers etc. These were answered via Q&A, but not captured in a systematic way for others with the same questions.
We need a way to capture clarifications and Q&A. Could we take a
copy of Lars's paper and perhaps extend as unanswered questions are raised and answered. Then that Paper would become an excellent bridging tool until the spec is written and available.
The specifications written for specific pieces of the language are that way to capture clarifications and Q&A, I think. In some sense the RI captures them too, but does not capture the broader discussion about what was not done. Prose does that better.
I would be happy to re-read and come up with questions that we
have that are still unanswered or unclear.
> "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."
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.
Agree that those lists are not worth debating, but definitely
worth sharing. It would help sway some of our priority discussions.
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.
Agree. I'm very thankful for all the efforts that the group have
invested in the language. It is easy to come late to the party and not understand the wisdom that has been expended in many conversations and prior debates.
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.
Understand. We are happy with this risk. In fact, most
implementations will innovate at the edges. This is the way we gain real experience for future drafts of the language.
> "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.
Could Graydon give a snapshot of what is not implemented in the
RI in terms of the proposals / features? I know the trac database lists all, but a punch list of the high priority deficits would be helpful.
>"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 tuning)?
For #2, we are quite happy to risk shipping features prior to
standardization and we will do our very best to adapt, change and track the standard. We are pretty up front with users on this front.
Regarding #1, I may not possess the skill to write
specifications. My skills are more as an implementer than a language designer and even less as a writer. I find that I pale when compared to other more leading lights in this regard.
Even so, the ability to attack a feature and ask questions about how it should behave and find answers to those questions comes so close to being a spec that it's probably good enough to be useful. The editors (myself and Jeff at this point) will still have to clean it up to incorporate it into the language spec; the original author will need to participate in that iterative process but will presumably not need to spend time on cleaning up the writing.
--lars
>"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 forward."
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 done.
Your welcome. We are looking forward to releasing our first
snapshot soon.
Michael
Jd
On 2/15/08 11:20 PM, Michael O'Brien wrote:
Jeff,
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 below:
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 inaccurate.
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 forward.
thanks
Michael O'Brien
Mbedthis Software
Jeff Dyer wrote:
Hi,
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.
WORKFLOW
The basic workflow:
Proposal -->
Implementation -->
Feature spec -->
Feature review -->
ES4-RI -->
ES4 spec -->
Proposal - see
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 process.
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.
SCHEDULE
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
Michael O'Brien wrote:
Could Graydon give a snapshot of what is not implemented in the RI in terms of the proposals / features? I know the trac database lists all, but a punch list of the high priority deficits would be helpful.
Sure. I can describe the state of most issues as named by the proposals page, I think. Some of the proposals have sort of no-longer-sensible names so I'm going to use the proposals page as a rough guide and name the things that have seemed, in my work, to be separate "features" of the RI.
Implemented, may have bugs:
- classes and interfaces
- namespaces
- pragmas
- let, const, let-const
- iterators
- enumerability control
- type expressions / definitions / annotations
- runtime type checks ("standard mode")
- nullability
- destructuring assignment
- slice syntax
- hashcode
- catchalls
- map & vector
- date & time improvements
- meta objects
- static generics
- string trim
- typeof
- globals
- expression closures
- name objects
- type operators (is / to / cast / wrap)
Implemented and partly working, but still in flux / work to do:
- inheritance checking
- strict mode
- type parameters
- structural types
- numbers & decimal
- getters & setters (structural part is incomplete)
- packages
Partially implemented / not yet working:
- program units
- generic function
- updates to unicode
- updates to regexps
Unimplemented:
- generators
- tail calls
- triple quotes
- stack inspection
- reformed with
- resurrected eval (eval exists but may be wrong)
- help for the argument object
- "this function" / "this generator"
In my mind the "high priority" deficits where I actually know what to do are:
- extending strict mode
- extending the part of the definer that checks inheritance
The remaining issues on my list all involve some spec/discussion work (units and packages, type parameters, structural typechecks, tail calls, reformed rules for with/this/eval/arguments)
How about hosting a set of unit tests at www.ecmascript.org?
In a sense, we already do; our unit tests are included in the source download. But it could be a good idea to make the tests independently available on the web site. We should probably make it clear that these don't carry any special or official weight of "conformance", however
Graydon,
Thanks -- that helps to understand the status.
You are in a somewhat unique position having implemented more than any other. Given Jeff's roadmap outline and the goal of weighing the features against implementation experience -- which of the features that you have implemented do you feel were difficult, costly or problematic?
In our implementation (Ejscript), we have implemented (with bugs):
- classes
- namespaces, including use pragmas
- block scope
- packages
- units
- pragmas
- let, const, let-const
- type expressions / definitions / annotations
- runtime type checks ("standard mode")
- destructuring assignment
- hashcode
- meta objects
- strict mode (incomplete checking)
- type parameters
- numbers & decimal
- getters & setters
Namespaces was a much bigger and more intrusive change that I first anticipated. Difficult to get it to perform well, but we're still working on it. However, once byte-code is generated for bound code, there is no cost. Similarly, block scope added considerable complexity. Program units were fairly straight forward as is strict mode and pragmas.
Structural types and type checking is next on our high priority list.
Michael
Michael O'Brien wrote:
Graydon,
Thanks -- that helps to understand the status.
You are in a somewhat unique position having implemented more than any other. Given Jeff's roadmap outline and the goal of weighing the features against implementation experience -- which of the features that you have implemented do you feel were difficult, costly or problematic?
Actually, despite my having acquired some sort of "RI maintainer" moniker, I did not write the majority of it. By volume I think the largest parts have come from Adobe and Opera people. The builtins and frontend each weigh about as much as the remainder (machine model, evaluator, type system).
My sense was that I had the most difficulty with the type and scope rules, but not so much because they were "problematic" as much as that we kept changing the rules. Also that even a minor bug in the rules typically produces a non-booting system, as the builtins stop working.
There was also (and continues to be) considerable subtlety in wiring up convincing builtin classes that behave "the same" as the ES3 primitives and ad-hoc host objects.
I can certainly imagine your experience though: if one doesn't have namespaces or the "proper" block scope forms in the system to start with, retrofitting them will likely be annoying. Likewise types. But the RI had some portion of these from the get-go (we retrofitted a unified scope-initialization primitive into it once the rules became clear half way in, and this was costly).
Structural types will probably pose a bit of pain because they require a type-term normalizer with some subtle parts. There is an example in type.sml but it's certainly not the sort that illuminates the subtle points! It should be cleaned up during spec'ing. That normalizer also gets significantly weirder once you introduce type parameters (it turns into a sort of partial evaluator).
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.
WORKFLOW
The basic workflow:
Proposal --> Implementation --> Feature spec --> Feature review --> ES4-RI --> ES4 spec -->
Proposal - see 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 process.
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.
SCHEDULE
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
May - draft 2
Jul - draft 3
Sep - draft 4
Oct - final draft
Hi, 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. WORKFLOW 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 process. 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. SCHEDULE 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