ODF still fails to specify scripting properly (ODF 1.2 CD01)

["Alex Brown" <alexb@griffinbrown.co.uk>]

Dear all,

ODF 1.2 prescribes no scripting language, but leaves this as a free choice for the implementer. All we are told is:

"The <office:script> element contains a script." (2.14)

As a result, any promise of interoperability resulting from the new "pure" conformance class is extremely weak, as conforming implementation are free to pick differing scripting languages or (worse) to implement similar scripting languages in divergent and non-interoperable ways.

The "pure" conformance class must normatively specify a scripting language that conforming implementations are mandated to support; the "extended" conformance class may of course be permissive about scripting languages.

Some readers may remember DIS 29500 drew a lot of heat for its underspecified scripting. Rob Weir wrote a wise and useful blog post on this (http://is.gd/lifs) - for convenience, here are the main requirements for interoperable scripting specification set out in that post; they say a script's host standard must define:

* How and where a script is stored and located within the Open Packaging Convention (OPC) container file.
* How is the script bound to the document. In other words, how does the document content associate itself with the macro?
* What is the runtime language of the script?
* What is the core and extension API's available to the script?
* What is the security model?
    
The three last points, in particular, are not addressed by the current ODF 1.2 draft. This is unacceptable.
    
I propose the following:

* ODF adopts a standardised scripting language - preferably ISO/IEC 16262 (ECMAScript)

* The native API onto an ODF document/application is defined and documented; general purpose libraries otherwise available are similarly documented

* Attention is paid to script operations that impact security, and a restrictive mode of operation defined which outlaws the use of risky scripting features.

- Alex.