On Oct 12, 2011, at 9:28 AM, Rick Waldron wrote: > Allen, > > Have you considered moving the spec drafting to a revision controlled system, > such as git? Michael Smith maintains an annotated and hyperlinked version of > ES5.1 here http://es5.github.com/. A system like this would certainly make > your maintenance tasks easier, in addition to facilitating a simplified > workfow for creating experimental versions.
The formal standards process is still targeted towards producing paper documents and Ecma currently requires that these documents be delivered in MS Word format and follow specific styling guidelines (there is what is essentially an ISO standard for standards that we are supposed to follow). Ecma-262 is a complex document. Edition 6 is likely to exceed 300 pages. While Word is far from perfect, it actually provides reasonable support and tooling for documents of that size. It isn't clear to me how github would help with such a document. While I have no fundamental objection to an HTML based document and editing environment, I have no interest to reverting to doing manual formatting markug. I moved beyond that technology around 1985. I've yet to see HTML document tooling that addresses the WYSIWYG production of documents of this complexity. It they are out there I would like to hear about them. Allen > > Rick > > On Wed, Oct 12, 2011 at 2:53 AM, Andreas Rossberg <[email protected]> wrote: > On 12 October 2011 02:32, Allen Wirfs-Brock <[email protected]> wrote: > > The experiments are shown > > in > > http://wiki.ecmascript.org/lib/exe/fetch.php?id=harmony%3Aspecification_drafts&cache=cache&media=harmony:11.1.5-alternatives.pdf > > This contains four versions of section 11.5.1 (Object literals). Each > > section is about 4 pages long and contains the same specification text, but > > organized in slightly different ways. > > The first version is what is currently in the specification. All the > > semantics definitions are lumped together in a single "Semantics" section in > > roughly the same order as the productions occur in the grammar. Each > > definition includes the grammar production it applies to so the order > > doesn't have any semantic significance. > > The second version regroups the semantic functions according to semantic > > function. First there are all the static semantic definitions for all the > > productions. Then all the PropertyDefinitionList function definitions for > > the productions that define it, and so until finally there are the > > evaluation function definitions for all the productions. > > The third version is ordered just like the second version but it uses > > explicit subsection headings for each function group in order to make them > > more visible. > > The four version orders everything by grammar production. It shows a > > production and immediately has all the functions that apply to that > > production. > > The third version seems far superior. It makes a proper, visible > separation between static semantics and dynamic semantics, which is > very helpful, and standard practice as well. > > In fact, you could be even more consistent about the triptych > syntax/static semantics/dynamic semantics by grouping all of the > latter in a subsection as well. That would be my preferred structure. > (If you worry about having too many levels of numbering you might want > to avoid numbering the individual bits of the dynamic semantics in > that case. I think their section numbers are a minor concern.) > > (BTW, in addition to a better structure, I have to agree with Claus > that having hyperlinks in the PDF would be a real blessing. I don't > know how much work that would be, though.) > > /Andreas > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
