[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [office-comment] ODF still fails to specify scripting properly (ODF 1.2CD01)
"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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]