RE: [office-comment] ODF still fails to specify scripting properly (ODF 1.2CD01)

[robert_weir@us.ibm.com]

"Alex Brown" <alexb@griffinbrown.co.uk> wrote on 03/01/2009 02:57:46 PM:

> 
> Rob hi
> 
> > I'm making a distinction between perfecting the ODF 1.2 draft versus
> an
> > expansion of scope.  The issue is not that we define a scripting
> > interface
> > poorly.  The issue is that we don't define one at all.  The easy part
> > is
> > specifying a language to use, say EcmaScript, and how it is
> > stored/declared in the file.  The hard part is that you would also
> need
> > to
> > specify the runtime API that the script has available to it, the
> > setCellFormat("Currency", 2) and similar functions.  That is a large
> > expansion in scope and is something that we have no available external
> > standards to tap into nor any member contributions.
> 
> You *do* have an external standard to tap into: Javascript (ECMAscript).
> Also, isn't there existing implementation of scripting in things like
> http://framework.openoffice.org/ which could help you?
> 

And I did mention EcmaScript explicitly in what I wrote, approximate a 
dozen lines above.  (You do read what I write, don't you?)

The point is the scripting language does not specify the runtime model 
available to the scripting language.  The interesting part is not 
EcmaScript's ability to add numbers and concatenate strings.  The 
interesting part is how that scripting language interacts with the runtime 
object model, the objects and methods that apply to workbooks, cells, 
slides, etc. 

And this isn't Ecma.  We're not going to just take OpenOffice's 
application framework and slap a cover sheet on it and call it a standard. 
 If we expanded the scope to include that, it would need to involve many 
stakeholders and broad discussion.  Not that this is a bad thing.  But it 
is out of scope for ODF 1.2

> In your blog piece which I initially referred to, you wrote "[...]
> scripting capabilities are essential for the creation of high-value
> scripted documents. These features are essential in modern applications.
> [...] This lack will cause serious interoperability concerns, as each
> vendor, lacking standards guidance, will implement these features in
> incompatible ways."
> 
> So, I agree with (the former) you. We must conclude that ODF as now
> drafted lacks an *essential* feature. That is a defect. A serious one. I
> want ODF to be full-featured, not lacking the ability to create the kind
> of interoperable "high-value scripted documents" you rightly talked of.
> 

Your sophistry is showing.  You are conflating two meanings of "essential" 
as well as two meanings of "defect", and rather poorly at that. 

We're not obliged to solve all of the world's problems in ODF 1.2.  We 
state a scope, and work within that scope.  The scope may expand from 
release to release as we tackle other issues.  But there is no particular 
requirement for any particular ODF revision to meet needs outside of that 
scope. ODF will not be perfect until it stops evolving.  Until then it 
will have defects (the absence of perfection).  There are many places I'd 
like to take ODF-Next to, including runtime automation.  I think it was 
Woody Allen who said "Time is nature's way of keeping everything from 
happening at once."  In a similar way, numbered revisions are the way we 
chunk up the stream of standards evolution into a timely and consumable 
set of discrete updates.

> Tell me, are these features any less "essential" now, than when you
> wrote that blog entry? Are your "serious interoperability concerns" now
> so easily trumped by the need to get an ODF draft out?
> 

I'd love to see document automation specified.  But I also realize that it 
is unnecessary for my wishes in this area to hold up the good work that 
has already been done in other parts of ODF 1.2.  My desires around 
automation are not incompatible with others' desires to see ODF 1.2 
completed.  To think otherwise would mean that you or I could spend many 
months defining automation API's for ODF 1.2, and find that this is held 
up, as someone else discovers some other feature that they want.

Rule #1 -- We're not required to solve all of the world's problems
Rule #2 -- Or at least not all at once.

> I don't think the argument about "member contributions" cuts it _at
> all_. If the ODF TC isn't sufficiently resourced (which, I suspect, may
> be the case) to produce a standard which covers the "essential" bases in
> the timeframe that has been self-imposed, then that doesn't grant it
> some kind of special dispensation to have a defective, half-baked spec.
> approved as a standard: probably not in OASIS, and almost certainly not
> in JTC 1. 
> 

Again, this isn't Ecma.  We just can't just have one company throw 
corporate resources at the problem and pay consultants to write thousands 
of pages of additional specification and then slap a cover sheet on it and 
call it a standard.  Writing the text is not the time consuming part.  The 
hard part is getting a text that is suitable for the various vendors and 
stakeholders on the TC, getting members to agree on this, and then getting 
the three conformant implementations that are required before we can 
approve an OASIS Standard.

In any case, we'll finish baking the cake.  That is what a draft is for. 
It is expected to be half-baked. But it is too late to suggest that we 
turn a half-baked chocolate cake into a fully-baked pineapple cake.  The 
scope for ODF 1.2 is set.  You'll need to wait for the next cake... uh.. 
ODF revision.

-Rob