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.
It would be interesting to know what tools were used to generate
the HTML version from the PDF - somewhere in that toolchain,
hyperlinks were added.
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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
