<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Jeff,<br>
<br>
Thanks for outlining the process to go forward.&nbsp; 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:<br>
<br>
1. What actually are the proposals?<br>
<blockquote>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.<br>
  <br>
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. <br>
  <br>
So my question is what are the agreed set of proposals and where are
they adequately documented?<br>
  <br>
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.<br>
</blockquote>
2. The RI is a key implementation too.<br>
<blockquote>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.<br>
</blockquote>
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?<br>
<br>
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.<br>
<br>
thanks<br>
<br>
<br>
Michael O'Brien<br>
Mbedthis Software<br>
<br>
<br>
Jeff Dyer wrote:
<blockquote cite="mid:C3DB8C90.11BC8%25jodyer@adobe.com" type="cite">
  <pre wrap="">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 --&gt;
     Implementation --&gt;
        Feature spec --&gt;
           Feature review --&gt;
              ES4-RI --&gt;
                 ES4 spec --&gt;

Proposal - see <a class="moz-txt-link-freetext" href="http://wiki.ecmascript.org/doku.php?id=proposals:proposals">http://wiki.ecmascript.org/doku.php?id=proposals:proposals</a>.
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


_______________________________________________
Es4-discuss mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Es4-discuss@mozilla.org">Es4-discuss@mozilla.org</a>
<a class="moz-txt-link-freetext" href="https://mail.mozilla.org/listinfo/es4-discuss">https://mail.mozilla.org/listinfo/es4-discuss</a>

  </pre>
</blockquote>
</body>
</html>